From nobody Sat May 1 01:27:26 2021 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4933D3A0AE4; Sat, 1 May 2021 01:27:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: avt@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: avt@ietf.org Message-ID: <161985764524.22528.9887753686668368087@ietfa.amsl.com> Date: Sat, 01 May 2021 01:27:25 -0700 Archived-At: Subject: [AVTCORE] I-D Action: draft-ietf-payload-rtp-jpegxs-10.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2021 08:27:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance WG of the IETF. Title : RTP Payload Format for ISO/IEC 21122 (JPEG XS) Authors : Sébastien Lugan Antonin Descampe Corentin Damman Thomas Richter Tim Bruylants Filename : draft-ietf-payload-rtp-jpegxs-10.txt Pages : 28 Date : 2021-05-01 Abstract: This document specifies a Real-Time Transport Protocol (RTP) payload format to be used for transporting JPEG XS (ISO/IEC 21122) encoded video. JPEG XS is a low-latency, lightweight image coding system. Compared to an uncompressed video use case, it allows higher resolutions and frame rates, while offering visually lossless quality, reduced power consumption, and end-to-end latency confined to a fraction of a frame. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-jpegxs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-payload-rtp-jpegxs-10 https://datatracker.ietf.org/doc/html/draft-ietf-payload-rtp-jpegxs-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-jpegxs-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat May 1 02:00:24 2021 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6640B3A0E1F; Sat, 1 May 2021 02:00:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: avt@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: avt@ietf.org Message-ID: <161985962237.12252.12417781733136926642@ietfa.amsl.com> Date: Sat, 01 May 2021 02:00:22 -0700 Archived-At: Subject: [AVTCORE] I-D Action: draft-ietf-payload-rtp-jpegxs-11.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2021 09:00:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance WG of the IETF. Title : RTP Payload Format for ISO/IEC 21122 (JPEG XS) Authors : Sébastien Lugan Antonin Descampe Corentin Damman Thomas Richter Tim Bruylants Filename : draft-ietf-payload-rtp-jpegxs-11.txt Pages : 28 Date : 2021-05-01 Abstract: This document specifies a Real-Time Transport Protocol (RTP) payload format to be used for transporting JPEG XS (ISO/IEC 21122) encoded video. JPEG XS is a low-latency, lightweight image coding system. Compared to an uncompressed video use case, it allows higher resolutions and frame rates, while offering visually lossless quality, reduced power consumption, and end-to-end latency confined to a fraction of a frame. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-jpegxs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-payload-rtp-jpegxs-11 https://datatracker.ietf.org/doc/html/draft-ietf-payload-rtp-jpegxs-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-jpegxs-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat May 1 03:03:43 2021 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5420E3A11A2; Sat, 1 May 2021 03:03:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: avt@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: avt@ietf.org Message-ID: <161986342128.11480.17427558408624697101@ietfa.amsl.com> Date: Sat, 01 May 2021 03:03:41 -0700 Archived-At: Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-multi-party-rtt-mix-16.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2021 10:03:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance WG of the IETF. Title : RTP-mixer formatting of multi-party Real-time text Author : Gunnar Hellstrom Filename : draft-ietf-avtcore-multi-party-rtt-mix-16.txt Pages : 46 Date : 2021-05-01 Abstract: Enhancements for RFC 4103 real-time text mixing are provided in this document, suitable for a centralized conference model that enables source identification and rapidly interleaved transmission of text from different sources. The intended use is for real-time text mixers and participant endpoints capable of providing an efficient presentation or other treatment of a multi-party real-time text session. The specified mechanism builds on the standard use of the CSRC list in the RTP packet for source identification. The method makes use of the same "text/t140" and "text/red" formats as for two- party sessions. Solutions using multiple RTP streams in the same RTP session are briefly mentioned, as they could have some benefits over the RTP- mixer model. The possibility to implement the solution in a wide range of existing RTP implementations made the RTP-mixer model be selected to be fully specified in this document. A capability exchange is specified so that it can be verified that a mixer and a participant can handle the multi-party coded real-time text stream using the RTP-mixer method. The capability is indicated by use of an SDP media attribute "rtt-mixer". The document updates RFC 4103 "RTP Payload for Text Conversation". A specification of how a mixer can format text for the case when the endpoint is not multi-party aware is also provided. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-avtcore-multi-party-rtt-mix-16.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-multi-party-rtt-mix-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun May 2 10:33:02 2021 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6688C3A043E; Sun, 2 May 2021 10:33:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Bernard Aboba via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Ali Begen , avt@ietf.org, avtcore-chairs@ietf.org, bernard.aboba@gmail.com, iesg-secretary@ietf.org Message-ID: <161997678040.13123.3728735674575058132@ietfa.amsl.com> Date: Sun, 02 May 2021 10:33:00 -0700 Archived-At: Subject: [AVTCORE] Publication has been requested for draft-ietf-payload-rtp-jpegxs-11 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 May 2021 17:33:01 -0000 Bernard Aboba has requested publication of draft-ietf-payload-rtp-jpegxs-11 as Proposed Standard on behalf of the AVTCORE working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-jpegxs/ From nobody Sun May 2 21:16:40 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7533A1EB9 for ; Sun, 2 May 2021 21:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sz1FTBjAt7U6 for ; Sun, 2 May 2021 21:16:38 -0700 (PDT) Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED8D73A1EB8 for ; Sun, 2 May 2021 21:16:37 -0700 (PDT) Received: by mail-vk1-xa33.google.com with SMTP id o17so975161vko.8 for ; Sun, 02 May 2021 21:16:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Syx2hY8W3EdAwc5UICjW/O/Z8f7l2cQLFJn2Ti5+gIk=; b=r7DEC2guqhVexRLWPgAuOWC8fa0Ype/TkQGwSjz0tfTrugyZBXnOBSivqFqPA31eiQ jPF8ygnHzep/Vq8LUwZqNGCmsQNrXTPeFmaieKE0BHisgQf2AZWm8j/1owIohqJ14z/B gH5L2+5Q+A9b5nLPpSIaXjULdz1cV/L6qisRDQsnk/UWdeLxfCwuYGY0t0hy3CpSpQPY hI1KLKiAUw7TgTvor3Z3qjDkGT4btjXAvINUmSFn8HhZVqjcEm18PvICyo/dpTJNEVaP 9UuRbRensCwQnIPo5CfTU9Zn8xg0TRUerzqbWQxI4JG/XEBIIyh+5QPz1zYLs8M2r1zk uZGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Syx2hY8W3EdAwc5UICjW/O/Z8f7l2cQLFJn2Ti5+gIk=; b=CiIzYu/doZUK6fi8pSzcKQbFdjEVLdhHj/urdzvHWHJlSI3Qppz2Sv6QvHciDa9QcZ niqo0fpa+UFJmT5GYAZIe1F+EVHebe4rtFRWE1RINA2lc04iZjsUrCJo2z0jQRF33WAe TeawKRP0kpLe1Hcc2Ipq+TlfWQKsno0QUzVYeynEvDZFxhZRMfDsnP/0/+mPUTLUbHGk RJfNOvCSTdwqLC/AwTs2I8o9f4qt7ay5Z83L4MeFv0qPboNOeAa/5ZRp+KbFjv9A/BR7 Ng1p6KFiJFcG4coPcbcU/ofEzVdBYXP36+ufZIqdUtITCNN8zIjOG76t8+lMMMgpt4w0 KH/A== X-Gm-Message-State: AOAM5322880nmH1TAtJFLnwsfXxB2VFM5UPzEAQMWzrsv8UwdQv+oRfS +gyv1NpsvZS4jLc0qsnYH1TkjHL/m10M6S5w+aTcorDi1v3/Xw== X-Google-Smtp-Source: ABdhPJw/z3uMFJ4FBX9K6wnA8ZvW1Vn9u6rXrSKV9iCFnG0PW3kcVkMxVSZO8y6pWkkD4x+8XeG29Ccax6mQApxu8qo= X-Received: by 2002:a1f:bf83:: with SMTP id p125mr10177350vkf.14.1620015395610; Sun, 02 May 2021 21:16:35 -0700 (PDT) MIME-Version: 1.0 From: "Murray S. Kucherawy" Date: Sun, 2 May 2021 21:16:24 -0700 Message-ID: To: avtcore@ietf.org Content-Type: multipart/alternative; boundary="0000000000002fa67105c1653aa1" Archived-At: Subject: [AVTCORE] AD Review of draft-ietf-payload-rtp-jpegxs-11 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 04:16:39 -0000 --0000000000002fa67105c1653aa1 Content-Type: text/plain; charset="UTF-8" Hi there, here's my AD Review of this document. Per the shepherd writeup, I have requested a review by the SDP Directorate. First: In the shepherd writeup, please correct the spelling of my name. :-) Also, while we're in there, question (12) asks what reviews were done, but the answer simply says that the document contains a media type registration, which doesn't really answer the question. Were any of the media type review resources asked for feedback on this? Later on the shepherd says he reviewed it, but it doesn't say what official reviews may have been undertaken. As you can see later on, there's a good chunk of the registration missing. In Section 2, please update the BCP 14 text to use the new form (see RFC 8174, which must also be added as a normative reference). Also in Section 2, the term "SOC Marker", though defined here, is not used below here. Section 3.2 references the EOC Marker; should it reference both? In Section 4, we encounter "SSRC" for the first time. A definition for it would be helpful, or a reference. In Section 4.2, "As per specified" can just be "As specified". Alternatively, "As per RFC 3550, ..." While I'm thinking about it, all these double references (e.g., "RFC 3550 [RFC3550]") throughout the document could be cleaned up. The diagrams in Section 4.4 show (eventually) how the EOC marker fits into this, but not the SOC marker. Should they? Section 4.5 uses a SHOULD. SHOULD leaves the implementer with a choice, so it's a good idea to include guidance about when one might legitimately do something other than what the SHOULD says to do. Or, if there isn't any, maybe this ought to be a SHALL? In Section 6.1, it's clear what a receiver would do with some of the optional parameters when they are absent (i.e., defaults are clear), but not in all cases. What can a receiver safely assume about "depth", "width", or "height", for example, when not specified? Also on 6.1, this media type registration is missing required fields, including "Interoperability Considerations", "Published Specification", "Applications that use this media type", "Fragment identifier considerations", "Additional information" (which has four sub-fields", "Contact information", "Intended Usage", "Restrictions On Usage", "Author", and "Change Controller". Please see RFC 6838. Further, it would probably be a good idea to mention either in the registration or in the Security Considerations of this document that the payload being registered does not (or does) contain code that is executable. The media type reviewers prefer people to be explicit on this point. -MSK --0000000000002fa67105c1653aa1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi there, here's my AD Review of this document.
Per the shepherd writeup, I have requested a review by the= SDP Directorate.

First: In the shepherd writeup, = please correct the spelling of my name.=C2=A0 :-)=C2=A0 Also, while we'= re in there, question (12) asks what reviews were done, but the answer simp= ly says that the document contains a media type registration, which doesn&#= 39;t really answer the question.=C2=A0 Were any of the media type review re= sources asked for feedback on this?=C2=A0 Later on the shepherd says he rev= iewed it, but it doesn't say what official reviews may have been undert= aken.=C2=A0 As you can see later on, there's a good chunk of the regist= ration missing.

In Section 2, please update th= e BCP 14 text to use the new form (see RFC 8174, which must also be added a= s a normative reference).

Also in Section 2, the t= erm "SOC Marker", though defined here, is not used below here.=C2= =A0 Section 3.2 references the EOC Marker; should it reference both?
<= div>
In Section 4, we encounter "SSRC" for the firs= t time.=C2=A0 A definition for it would be helpful, or a reference.

In Section 4.2, "As per specified" can just be = "As specified".=C2=A0 Alternatively, "As per RFC 3550, ...&q= uot;=C2=A0 While I'm thinking about it, all these double references (e.= g., "RFC 3550 [RFC3550]") throughout the document could be cleane= d up.

The diagrams in Section 4.4 show (eventually= ) how the EOC marker fits into this, but not the SOC marker.=C2=A0 Should t= hey?

Section 4.5 uses a SHOULD.=C2=A0 SHOULD leave= s the implementer with a choice, so it's a good idea to include guidanc= e about when one might legitimately do something other than what the SHOULD= says to do.=C2=A0 Or, if there isn't any, maybe this ought to be a SHA= LL?

In Section 6.1, it's clear what a rece= iver would do with some of the optional parameters when they are absent (i.= e., defaults are clear), but not in all cases.=C2=A0 What can a receiver sa= fely assume about "depth", "width", or "height&quo= t;, for example, when not specified?

Also on 6.1, = this media type registration is missing required fields, including "In= teroperability Considerations", "Published Specification", &= quot;Applications that use this media type", "Fragment identifier= considerations", "Additional information" (which has four s= ub-fields", "Contact information", "Intended Usage"= ;, "Restrictions On Usage", "Author", and "Change = Controller".=C2=A0 Please see RFC 6838.=C2=A0 Further, it would probab= ly be a good idea to mention either in the registration or in the Security = Considerations of this document that the payload being registered does not = (or does) contain code that is executable.=C2=A0 The media type reviewers p= refer people to be explicit on this point.

-MSK
--0000000000002fa67105c1653aa1-- From nobody Mon May 3 07:55:41 2021 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F683A1720; Mon, 3 May 2021 07:55:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: avt@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: avt@ietf.org Message-ID: <162005373410.22075.6363231786339488701@ietfa.amsl.com> Date: Mon, 03 May 2021 07:55:34 -0700 Archived-At: Subject: [AVTCORE] I-D Action: draft-ietf-payload-rtp-jpegxs-12.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 14:55:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance WG of the IETF. Title : RTP Payload Format for ISO/IEC 21122 (JPEG XS) Authors : Sébastien Lugan Antonin Descampe Corentin Damman Thomas Richter Tim Bruylants Filename : draft-ietf-payload-rtp-jpegxs-12.txt Pages : 29 Date : 2021-05-03 Abstract: This document specifies a Real-Time Transport Protocol (RTP) payload format to be used for transporting JPEG XS (ISO/IEC 21122) encoded video. JPEG XS is a low-latency, lightweight image coding system. Compared to an uncompressed video use case, it allows higher resolutions and frame rates, while offering visually lossless quality, reduced power consumption, and end-to-end latency confined to a fraction of a frame. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-jpegxs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-payload-rtp-jpegxs-12 https://datatracker.ietf.org/doc/html/draft-ietf-payload-rtp-jpegxs-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-jpegxs-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 3 07:57:47 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176993A1713 for ; Mon, 3 May 2021 07:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=intopix.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TsYS3csO5Kc for ; Mon, 3 May 2021 07:57:40 -0700 (PDT) Received: from dispatchb-eu1.ppe-hosted.com (dispatchb-eu1.ppe-hosted.com [185.132.181.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77A603A1706 for ; Mon, 3 May 2021 07:57:40 -0700 (PDT) X-Virus-Scanned: Proofpoint Essentials engine Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04lp2055.outbound.protection.outlook.com [104.47.12.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1-eu1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 1C9FC40078; Mon, 3 May 2021 14:57:33 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EWEF93AlnxZ5b+DAVJzhDXDuNK77ZPfWd1JAENpgzlPEMSp/c/kU7RA7jmyFu/+g5J2fmSoECwMpDgQHFSdyWAKmYHYupU1OKx4Tc0+PCXcGAo4xQiPY7IODW0EHOVrb6z0WtPVGqePohjPoepgHBBDerwnOOHvinAL2xfOYbeVoikoIz/EKcPQKbNePH/Q1U1wZoAPPqvhllSggMoT+hmbsZj7K05TiAFWNoGWdETNuC6i6WST5XDUyb0frQ4Cnl0oHzMKyX5V0kezVbnVg+8TWgJLk36hzDXCKkDHi+39PfIcng0RJZR23iZtl3gASdXD2IMjeWwyKnI6iSsSLCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4rGEzhm2p/8FlTltpWf/ueV6zNE3/qBS4nmK8GM1WP4=; b=BVl9GAZnUAefQ5Oagq/rrHS4u9IPhfOr4Mr0N1ffku0P5QTKlNkmJZxLWrbuv5u+P5tWGO1rLGlk3yKkEiaHIqbrNZxFXcEahgrlHXhz2MjCgRj9JY0IjefD05P+ZrIYkwdJeCehhR5vG3WYxEHu7CTwvsn35tzRxwrv8sauILSZZWYdiWMeiW3T7HRwSkjUxl4QF9bX/J4timCdy0QQQsEmwR9za4GLeYvOlSh5wdJJzb9HCKd/nyYAtJ7oJnm8VFbRR62n7v6XWNkj4m6FgS7pa014drqxtfTUSgThqofjFplQsrrXxpUJzn/f4NG07Bji5m/pn1oM63/8UbYDDw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intopix.com; dmarc=pass action=none header.from=intopix.com; dkim=pass header.d=intopix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intopix.onmicrosoft.com; s=selector1-intopix-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4rGEzhm2p/8FlTltpWf/ueV6zNE3/qBS4nmK8GM1WP4=; b=VA/PMTI+Tlm4ySxKzL4Ih3aYgrJmiV2D367voUyIwr/CjADvIGbImJaCI/mM068L33ArmjCPajMzGvx0wbcVNkBHYEuqsCwOtB6kfgAf37bZyaoq/r7ZPCGd8TAhM/fc5h4KQPv5odZnOX4TB+SC+Rxfvz8iQcKKnqG3bwVd9ok= Received: from PR3P192MB0748.EURP192.PROD.OUTLOOK.COM (2603:10a6:102:4f::24) by PR3P192MB1005.EURP192.PROD.OUTLOOK.COM (2603:10a6:102:94::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.38; Mon, 3 May 2021 14:57:31 +0000 Received: from PR3P192MB0748.EURP192.PROD.OUTLOOK.COM ([fe80::f598:e21e:5658:281f]) by PR3P192MB0748.EURP192.PROD.OUTLOOK.COM ([fe80::f598:e21e:5658:281f%5]) with mapi id 15.20.4087.044; Mon, 3 May 2021 14:57:31 +0000 From: Tim Bruylants To: "Murray S. Kucherawy" , "avtcore@ietf.org" Thread-Topic: [AVTCORE] AD Review of draft-ietf-payload-rtp-jpegxs-11 Thread-Index: AQHXP9Mltk3wSOimukmUP9PlJGiJfKrR2ThA Date: Mon, 3 May 2021 14:57:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=intopix.com; x-originating-ip: [2a02:1810:1dbd:e901:9572:1c39:ee48:a399] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: afff8e4a-c527-4d80-d630-08d90e43c708 x-ms-traffictypediagnostic: PR3P192MB1005: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /BvLWwBjMbRIRwRJEzotmdJLmt+lW+ypX8fyYNY44D5dgrrBPWlHc76wFId8yuDdVwqhiE6ndbyPWSfb4x1sZXhd+zAyl5B0KsNwZfmQq3URtQ4Vgd7IP2a38pjqYxJcbxqOkIWKCUfm/ZQD0sJjuONGxyMCY3UEmHAJSqka1bnBf1fyhjxwg0hbG9gXoHvF+BSdzLp4A03/6aMJR4cx3aTgsNeccDJCORawLyib9Sd5BwsMv9V+rDQWQxj+wb9sP5dAX98CYeLTzOylkJOnjb8q2pk5OzFpGlDAoKcq3OPrQDcMyoKrGC+pt4KXoQSrEWTyaIoJPp3F5TxeRDk6ISzzX8TthYOK73OYdQvcvTxErYrirb3km9snaWHkCNbmjuG62gDZY8iVM5ZrKW0Nlqmvfo4zywikA6uCpGSkLaSxEpkRLaZex4M293Lr6mTMO0+vFHqYBKp1v26wJBwPk9wMmINQjldraPhnnuVqJKL/alyuq1U88a47C2qmOVFFvetqj4CDRt9bzlmO1yBiKuvv9k200NoXYRY9XB/a7pnBAzMGjGIsnhK3IFKUSU0TiJ9ov4WX/N9xdkyyKaCB7VjBHjGF+688+/QGkgTW3b8= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR3P192MB0748.EURP192.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(136003)(396003)(366004)(39830400003)(376002)(346002)(83380400001)(110136005)(66476007)(66556008)(64756008)(66446008)(2906002)(76116006)(7696005)(52536014)(186003)(5660300002)(478600001)(66946007)(53546011)(55016002)(38100700002)(122000001)(9686003)(33656002)(8676002)(71200400001)(86362001)(8936002)(316002)(6506007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?eXhGR0ZOWUs1S0tXTzhuanhzY3Q2K0VqSmdES3V2RklIeks4OGt5NTZ6NmFQ?= =?utf-8?B?a21UNysyVWoraFRiUmh2U1pteEV1NG9tZEIrRWdTTHFEdkV6OGlCdnB6bUdG?= =?utf-8?B?TGJQY2RwRGRqcjltZW9PaWxsMlJPY0lDQnUxZUQvQ3RENHF4YnRadU1ycVB5?= =?utf-8?B?RFpnOWdtRzdoMk82U1lhZTVTMmN0QXk1ejJ1NnpWa2sraW5tVGxQMlRFVFNv?= =?utf-8?B?QWQxcXpWNWFZdlhTUVFhRTMwcURlN2Z6RFBEUk5LQk1tQkYzKzM2TDdlRWU4?= =?utf-8?B?blRpNWVRcXhMUVV6NEFwNDRTLzIvMkdPMzQ0VGt1UTRMcWdsaFNEUVVYdDJx?= =?utf-8?B?MmFWU3RHWWZ4Y3BMVUNwWk1Eem4xNVRFZWIzOEp3eVFvWm8wZ3RScG9mQTQz?= =?utf-8?B?anVRRllNQnNKWHdKY0VMYUhMTlUyN1NhMXc1RVhPcDFhM090aFVRazRYcDdE?= =?utf-8?B?MnllSWorVDdFR01FSnNyVS9RdDdZVk9QaWJabzBTS082VGZ3K1dvQ09hM25s?= =?utf-8?B?aEZVL21nd2M1RUkwdWpPbVV5clBZeHVtQWxPaHVrTkIrQnAvbGlOT1BSSHBq?= =?utf-8?B?U2tYWFU4OFFlMXFkWEdNTXVYc3gyMFUxT2EyYUl2aDJObWs1T1R6R0lWa2tz?= =?utf-8?B?WTc2Q1ExRFJSc2U3Q244c3ozWnM3YWVDRVVvcGhNN2Q3VThYbXBBdW91Sk9Y?= =?utf-8?B?RDdFZ2VTTER1QTIvYTBiY0IrQjY5MXYrSGN3TFNuZG4xekl4VHpSMXhyb1Jl?= =?utf-8?B?OElUY2dYWFR5ZlBEVFZiTmNPbWJhU1dzeGFCeFVqaDk5U1pveWJGVVNqRk1w?= =?utf-8?B?YndYUi9TSjlySkNiMTRPSWpHYXNWYmRxbmNrUzNJTGZaV2VXOWpCdGg5NlFN?= =?utf-8?B?NDMzTDlWc2VtOW1hQy9HRU92NzB2YjFlaU9Ud0s4VksvalVjY3FMUWJoVmNq?= =?utf-8?B?b0RPejd2bUhBYisxdFdDNDNzdWkzM2hSK3UzZVU5RzlxWHhVWk04MW9sQUNm?= =?utf-8?B?REFkWDRiU2Y5cWVGQ3ZuUzgxQUptN1JIOHlidnRIRnR1ZlBsYlExb3VLNDhj?= =?utf-8?B?TUhON0JoaWVSbCt4cHh5VlR6NHVtK3lJUlJyK3U5bHZJY3FDd2tONi8wejlB?= =?utf-8?B?ZW5UZWNsUVZIMHN1YmtaTEZtbDEwZTB3QUhDa0NQOWhiWWtTZUIyVVJIMzRK?= =?utf-8?B?Z2Rpa2xkTkRVWUpSeHR0UFlEWCtGVDJPRlAzSTZXZzRhUHFRSzE5Y0J5WURo?= =?utf-8?B?MTZwaUdsa29MajBkbmpyRnRKQzh0bkFvKzFsa2Z3eVowNFNjRG5hNDVkZ05I?= =?utf-8?B?WCswbkhMUk1YdkZCWUdjWlBjRWpVLy9IYXlnQVIrNWxURnpzdXlkaTdteENG?= =?utf-8?B?UStwYXd5VDV4eDhiWjEvbzlRVW5KcXU3YlQya0phVFR3elNyTTFHU1dwUjVC?= =?utf-8?B?Wk5QVmtCNDB2NVY3MFAyT0RSWUhwVlRoMk9JTHhvSzk1dWt0Tlp4b3FCcnB3?= =?utf-8?B?VDBVYTcveERxZ1hpeGRqQkhkVDl4VnhkNFdnWE40WEl1SkM1MVZkeTJJb2U4?= =?utf-8?B?K2NrRzZLME1NS0M3YWFNcjAvYThlejJleFdBSnVIUW9DSGhIREpISjFBTmlR?= =?utf-8?B?aFRRUFJkUVExV3UyOTNydVNjcjVBVE1HZk9pNTYzSFBjNnprQ3paUjRRNFBw?= =?utf-8?B?L1I0WU85dkR2T3l2VE9Ib0FURnY1NXpSUEErTWVMZjdteVkzVk5teHUySnkx?= =?utf-8?B?VjMraHZVZ2xTdjFOSTB3VkU0c290eFkzYnB0c2g1WmNCVTJSV2FPR0RNbDRC?= =?utf-8?B?aUhPdm1SeDFwOG95Tkp0K3RUR0lCL2c3alVFSnBEUkYzdDllNjB2WjQ1aStn?= =?utf-8?Q?At8c3oF7nAOIK?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_PR3P192MB0748D48268FFC24A1BBE1DC4AC5B9PR3P192MB0748EURP_" MIME-Version: 1.0 X-OriginatorOrg: intopix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PR3P192MB0748.EURP192.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: afff8e4a-c527-4d80-d630-08d90e43c708 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2021 14:57:31.3383 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5f9168c7-cdac-4b23-9509-c278399e3c1f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vz0etYggQnv7Z3do5wN898YsR+3mpt3X342Y/B3rPkN2/We0nPQS6IA7kizEwMH4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3P192MB1005 X-MDID: 1620053853-NYFr4CAXObzv Archived-At: Subject: Re: [AVTCORE] AD Review of draft-ietf-payload-rtp-jpegxs-11 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 14:57:45 -0000 --_000_PR3P192MB0748D48268FFC24A1BBE1DC4AC5B9PR3P192MB0748EURP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBNdXJyYXksDQoNClRoYW5rIHlvdSBmb3IgdGhlIHJldmlldy4gV2UgaGF2ZSBhZGRyZXNz ZWQgeW91ciBjb21tZW50cyBpbiBkcmFmdC1pZXRmLXBheWxvYWQtcnRwLWpwZWd4cy0xMi4NCg0K SGVyZSBpcyB0aGUgZGV0YWlsZWQgYW5zd2VyIHRvIHRoZSBjb21tZW50czoNCg0KPkluIFNlY3Rp b24gMiwgcGxlYXNlIHVwZGF0ZSB0aGUgQkNQIDE0IHRleHQgdG8gdXNlIHRoZSBuZXcgZm9ybSAo c2VlIFJGQyA4MTc0LCB3aGljaCBtdXN0IGFsc28gYmUgYWRkZWQgYXMgYSBub3JtYXRpdmUgcmVm ZXJlbmNlKS4NCg0KICBXZSBoYXZlIHVwZGF0ZWQgdGhlIHRleHQgdG8gY29tcGx5IHdpdGggUkZD IDgxNzQuDQoNCg0KDQo+IEFsc28gaW4gU2VjdGlvbiAyLCB0aGUgdGVybSAiU09DIE1hcmtlciIs IHRob3VnaCBkZWZpbmVkIGhlcmUsIGlzIG5vdCB1c2VkIGJlbG93IGhlcmUuICBTZWN0aW9uIDMu MiByZWZlcmVuY2VzIHRoZSBFT0MgTWFya2VyOyBzaG91bGQgaXQgcmVmZXJlbmNlIGJvdGg/DQoN CiAgMSkgVGhlIHRlcm0gIlNPQyBtYXJrZXIiIGlzIHVzZWQgaW4gc2VjdGlvbiAyIHVuZGVyICJK UEVHIFhTIGNvZGVzdHJlYW0gaGVhZGVyIi4NCiAgMikgV2UgY2xhcmlmaWVkIHNlY3Rpb24gMy4y LCByZWZlcmVuY2luZyAiU09DIG1hcmtlciIuDQoNCg0KDQo+IEluIFNlY3Rpb24gNCwgd2UgZW5j b3VudGVyICJTU1JDIiBmb3IgdGhlIGZpcnN0IHRpbWUuICBBIGRlZmluaXRpb24gZm9yIGl0IHdv dWxkIGJlIGhlbHBmdWwsIG9yIGEgcmVmZXJlbmNlLg0KDQogIFNTUkMgaXMgU3luY2hyb25pemF0 aW9uIFNvdXJjZSwgYXMgZGVmaW5lZCBpbiBSRkMzNTUwLiBXZSBtb2RpZmllZCB0aGUgdGV4dCB0 byBjbGFyaWZ5IHRoaXMuDQoNCg0KDQo+IEluIFNlY3Rpb24gNC4yLCAiQXMgcGVyIHNwZWNpZmll ZCIgY2FuIGp1c3QgYmUgIkFzIHNwZWNpZmllZCIuICBBbHRlcm5hdGl2ZWx5LCAiQXMgcGVyIFJG QyAzNTUwLCAuLi4iICBXaGlsZSBJJ20gdGhpbmtpbmcgYWJvdXQgaXQsIGFsbCB0aGVzZSBkb3Vi bGUgcmVmZXJlbmNlcyAoZS5nLiwgIlJGQyAzNTUwIFtSRkMzNTUwXSIpIHRocm91Z2hvdXQgdGhl IGRvY3VtZW50IGNvdWxkIGJlIGNsZWFuZWQgdXAuDQoNCiAgV2UgaGF2ZSBjbGVhbmVkIHVwIHRo ZSAiZG91YmxlIHJlZmVyZW5jZXMiIHRocm91Z2hvdXQgdGhlIHRleHQuDQoNCg0KDQo+IFRoZSBk aWFncmFtcyBpbiBTZWN0aW9uIDQuNCBzaG93IChldmVudHVhbGx5KSBob3cgdGhlIEVPQyBtYXJr ZXIgZml0cyBpbnRvIHRoaXMsIGJ1dCBub3QgdGhlIFNPQyBtYXJrZXIuICBTaG91bGQgdGhleT8N Cg0KICBXZSBjbGFyaWZpZWQgdGhhdCB0aGUgU09DIG1hcmtlciBpcyBwYXJ0IG9mIHRoZSBKUEVH IFhTIGNvZGVzdHJlYW0gaGVhZGVyLiBUaGUgbGF0dGVyIGlzIGNsZWFybHkgbWVudGlvbmVkIGlu IHRoZSBkaWFncmFtcy4gRXhwbGljaXRseSBtZW50aW9uaW5nIFNPQyBpbiB0aGUgZGlhZ3JhbXMg d291bGQgY2x1dHRlciB0aGUgbGF5b3V0LCBhbmQgd291bGQgcHJvYmFibHkgcmVxdWlyZSB0byBl eHBsaWNpdGx5IGFkZCB0aGUgb3RoZXIgbWFya2VycyBpbiB0aGUgY29kZXN0cmVhbSBoZWFkZXIg YXMgd2VsbC4NCg0KDQoNCj4gU2VjdGlvbiA0LjUgdXNlcyBhIFNIT1VMRC4gIFNIT1VMRCBsZWF2 ZXMgdGhlIGltcGxlbWVudGVyIHdpdGggYSBjaG9pY2UsIHNvIGl0J3MgYSBnb29kIGlkZWEgdG8g aW5jbHVkZSBndWlkYW5jZSBhYm91dCB3aGVuIG9uZSBtaWdodCBsZWdpdGltYXRlbHkgZG8gc29t ZXRoaW5nIG90aGVyIHRoYW4gd2hhdCB0aGUgU0hPVUxEIHNheXMgdG8gZG8uICBPciwgaWYgdGhl cmUgaXNuJ3QgYW55LCBtYXliZSB0aGlzIG91Z2h0IHRvIGJlIGEgU0hBTEw/DQoNCiAgV2UgcmV3 b3JkZWQgc2VjdGlvbiA0LjUgc2xpZ2h0bHkuIFRoZSBtZXNzYWdlIGlzIHRoYXQgYWN0dWFsIHRy YWZmaWMgc2hhcGluZyBhbmQgdGltaW5nIGRlbGl2ZXJ5IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9m IHRoaXMgc3BlY2lmaWNhdGlvbiBhbmQgZG9lcyBub3QgaW5mbHVlbmNlIHRoZSBwYXlsb2FkIHBh Y2tldGl6YXRpb24uIFdlIGFsc28gbW92ZWQgdGhlIHNlY3Rpb24gb25lIGxldmVsIHVwIChiZWNh bWUgc2VjdGlvbiA1KS4NCg0KDQoNCj4gSW4gU2VjdGlvbiA2LjEsIGl0J3MgY2xlYXIgd2hhdCBh IHJlY2VpdmVyIHdvdWxkIGRvIHdpdGggc29tZSBvZiB0aGUgb3B0aW9uYWwgcGFyYW1ldGVycyB3 aGVuIHRoZXkgYXJlIGFic2VudCAoaS5lLiwgZGVmYXVsdHMgYXJlIGNsZWFyKSwgYnV0IG5vdCBp biBhbGwgY2FzZXMuICBXaGF0IGNhbiBhIHJlY2VpdmVyIHNhZmVseSBhc3N1bWUgYWJvdXQgImRl cHRoIiwgIndpZHRoIiwgb3IgImhlaWdodCIsIGZvciBleGFtcGxlLCB3aGVuIG5vdCBzcGVjaWZp ZWQ/DQoNCiAgV2UgdGhvdWdodCB0aGlzIHdhcyBjbGFyaWZpZWQgYnkgc2VjdGlvbiA2LjIuMS4g TmV2ZXJ0aGVsZXNzLCB3ZSBhZGRlZCBhIHNob3J0IHBhcmFncmFwaCBpbiBzZWN0aW9uIDYgKG5v dyBzZWN0aW9uIDcpLg0KDQoNCg0KPiBBbHNvIG9uIDYuMSwgdGhpcyBtZWRpYSB0eXBlIHJlZ2lz dHJhdGlvbiBpcyBtaXNzaW5nIHJlcXVpcmVkIGZpZWxkcywgaW5jbHVkaW5nICJJbnRlcm9wZXJh YmlsaXR5IENvbnNpZGVyYXRpb25zIiwgIlB1Ymxpc2hlZCBTcGVjaWZpY2F0aW9uIiwgIkFwcGxp Y2F0aW9ucyB0aGF0IHVzZSB0aGlzIG1lZGlhIHR5cGUiLCAiRnJhZ21lbnQgaWRlbnRpZmllciBj b25zaWRlcmF0aW9ucyIsICJBZGRpdGlvbmFsIGluZm9ybWF0aW9uIiAod2hpY2ggaGFzIGZvdXIg c3ViLWZpZWxkcyIsICJDb250YWN0IGluZm9ybWF0aW9uIiwgIkludGVuZGVkIFVzYWdlIiwgIlJl c3RyaWN0aW9ucyBPbiBVc2FnZSIsICJBdXRob3IiLCBhbmQgIkNoYW5nZSBDb250cm9sbGVyIi4g IFBsZWFzZSBzZWUgUkZDIDY4MzguICBGdXJ0aGVyLCBpdCB3b3VsZCBwcm9iYWJseSBiZSBhIGdv b2QgaWRlYSB0byBtZW50aW9uIGVpdGhlciBpbiB0aGUgcmVnaXN0cmF0aW9uIG9yIGluIHRoZSBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucyBvZiB0aGlzIGRvY3VtZW50IHRoYXQgdGhlIHBheWxvYWQg YmVpbmcgcmVnaXN0ZXJlZCBkb2VzIG5vdCAob3IgZG9lcykgY29udGFpbiBjb2RlIHRoYXQgaXMg ZXhlY3V0YWJsZS4gIFRoZSBtZWRpYSB0eXBlIHJldmlld2VycyBwcmVmZXIgcGVvcGxlIHRvIGJl IGV4cGxpY2l0IG9uIHRoaXMgcG9pbnQuDQoNCiAgV2UgaGF2ZSByZXdvcmtlZCB0aGUgbWVkaWEg dHlwZSByZWdpc3RyYXRpb24gc2VjdGlvbiB0byBmb2xsb3cgUkZDIDY4MzggYW5kIFJGQyA0ODU1 Lg0KDQogIFdlIGFkZGVkIHRoZSBub3Rpb24gdGhhdCB0aGUgcGF5bG9hZCBmb3JtYXQgYW5kIHRo ZSBKUEVHIFhTIGVuY29kaW5nIGRvIE5PVCBjb250YWluIGV4ZWN1dGFibGUgY29kZSAodG8gdGhl IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24pLg0KDQoNCktpbmQgcmVnYXJkcywNClRp bSBCcnV5bGFudHMNCg0KDQoNCkZyb206IGF2dCA8YXZ0LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJl aGFsZiBPZiBNdXJyYXkgUy4gS3VjaGVyYXd5DQpTZW50OiBNb25kYXkgMyBNYXkgMjAyMSAwNjox Ng0KVG86IGF2dGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFtBVlRDT1JFXSBBRCBSZXZpZXcgb2Yg ZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1qcGVneHMtMTENCg0KSGkgdGhlcmUsIGhlcmUncyBteSBB RCBSZXZpZXcgb2YgdGhpcyBkb2N1bWVudC4NClBlciB0aGUgc2hlcGhlcmQgd3JpdGV1cCwgSSBo YXZlIHJlcXVlc3RlZCBhIHJldmlldyBieSB0aGUgU0RQIERpcmVjdG9yYXRlLg0KDQpGaXJzdDog SW4gdGhlIHNoZXBoZXJkIHdyaXRldXAsIHBsZWFzZSBjb3JyZWN0IHRoZSBzcGVsbGluZyBvZiBt eSBuYW1lLiAgOi0pICBBbHNvLCB3aGlsZSB3ZSdyZSBpbiB0aGVyZSwgcXVlc3Rpb24gKDEyKSBh c2tzIHdoYXQgcmV2aWV3cyB3ZXJlIGRvbmUsIGJ1dCB0aGUgYW5zd2VyIHNpbXBseSBzYXlzIHRo YXQgdGhlIGRvY3VtZW50IGNvbnRhaW5zIGEgbWVkaWEgdHlwZSByZWdpc3RyYXRpb24sIHdoaWNo IGRvZXNuJ3QgcmVhbGx5IGFuc3dlciB0aGUgcXVlc3Rpb24uICBXZXJlIGFueSBvZiB0aGUgbWVk aWEgdHlwZSByZXZpZXcgcmVzb3VyY2VzIGFza2VkIGZvciBmZWVkYmFjayBvbiB0aGlzPyAgTGF0 ZXIgb24gdGhlIHNoZXBoZXJkIHNheXMgaGUgcmV2aWV3ZWQgaXQsIGJ1dCBpdCBkb2Vzbid0IHNh eSB3aGF0IG9mZmljaWFsIHJldmlld3MgbWF5IGhhdmUgYmVlbiB1bmRlcnRha2VuLiAgQXMgeW91 IGNhbiBzZWUgbGF0ZXIgb24sIHRoZXJlJ3MgYSBnb29kIGNodW5rIG9mIHRoZSByZWdpc3RyYXRp b24gbWlzc2luZy4NCg0KSW4gU2VjdGlvbiAyLCBwbGVhc2UgdXBkYXRlIHRoZSBCQ1AgMTQgdGV4 dCB0byB1c2UgdGhlIG5ldyBmb3JtIChzZWUgUkZDIDgxNzQsIHdoaWNoIG11c3QgYWxzbyBiZSBh ZGRlZCBhcyBhIG5vcm1hdGl2ZSByZWZlcmVuY2UpLg0KDQpBbHNvIGluIFNlY3Rpb24gMiwgdGhl IHRlcm0gIlNPQyBNYXJrZXIiLCB0aG91Z2ggZGVmaW5lZCBoZXJlLCBpcyBub3QgdXNlZCBiZWxv dyBoZXJlLiAgU2VjdGlvbiAzLjIgcmVmZXJlbmNlcyB0aGUgRU9DIE1hcmtlcjsgc2hvdWxkIGl0 IHJlZmVyZW5jZSBib3RoPw0KDQpJbiBTZWN0aW9uIDQsIHdlIGVuY291bnRlciAiU1NSQyIgZm9y IHRoZSBmaXJzdCB0aW1lLiAgQSBkZWZpbml0aW9uIGZvciBpdCB3b3VsZCBiZSBoZWxwZnVsLCBv ciBhIHJlZmVyZW5jZS4NCg0KSW4gU2VjdGlvbiA0LjIsICJBcyBwZXIgc3BlY2lmaWVkIiBjYW4g anVzdCBiZSAiQXMgc3BlY2lmaWVkIi4gIEFsdGVybmF0aXZlbHksICJBcyBwZXIgUkZDIDM1NTAs IC4uLiIgIFdoaWxlIEknbSB0aGlua2luZyBhYm91dCBpdCwgYWxsIHRoZXNlIGRvdWJsZSByZWZl cmVuY2VzIChlLmcuLCAiUkZDIDM1NTAgW1JGQzM1NTBdIikgdGhyb3VnaG91dCB0aGUgZG9jdW1l bnQgY291bGQgYmUgY2xlYW5lZCB1cC4NCg0KVGhlIGRpYWdyYW1zIGluIFNlY3Rpb24gNC40IHNo b3cgKGV2ZW50dWFsbHkpIGhvdyB0aGUgRU9DIG1hcmtlciBmaXRzIGludG8gdGhpcywgYnV0IG5v dCB0aGUgU09DIG1hcmtlci4gIFNob3VsZCB0aGV5Pw0KDQpTZWN0aW9uIDQuNSB1c2VzIGEgU0hP VUxELiAgU0hPVUxEIGxlYXZlcyB0aGUgaW1wbGVtZW50ZXIgd2l0aCBhIGNob2ljZSwgc28gaXQn cyBhIGdvb2QgaWRlYSB0byBpbmNsdWRlIGd1aWRhbmNlIGFib3V0IHdoZW4gb25lIG1pZ2h0IGxl Z2l0aW1hdGVseSBkbyBzb21ldGhpbmcgb3RoZXIgdGhhbiB3aGF0IHRoZSBTSE9VTEQgc2F5cyB0 byBkby4gIE9yLCBpZiB0aGVyZSBpc24ndCBhbnksIG1heWJlIHRoaXMgb3VnaHQgdG8gYmUgYSBT SEFMTD8NCg0KSW4gU2VjdGlvbiA2LjEsIGl0J3MgY2xlYXIgd2hhdCBhIHJlY2VpdmVyIHdvdWxk IGRvIHdpdGggc29tZSBvZiB0aGUgb3B0aW9uYWwgcGFyYW1ldGVycyB3aGVuIHRoZXkgYXJlIGFi c2VudCAoaS5lLiwgZGVmYXVsdHMgYXJlIGNsZWFyKSwgYnV0IG5vdCBpbiBhbGwgY2FzZXMuICBX aGF0IGNhbiBhIHJlY2VpdmVyIHNhZmVseSBhc3N1bWUgYWJvdXQgImRlcHRoIiwgIndpZHRoIiwg b3IgImhlaWdodCIsIGZvciBleGFtcGxlLCB3aGVuIG5vdCBzcGVjaWZpZWQ/DQoNCkFsc28gb24g Ni4xLCB0aGlzIG1lZGlhIHR5cGUgcmVnaXN0cmF0aW9uIGlzIG1pc3NpbmcgcmVxdWlyZWQgZmll bGRzLCBpbmNsdWRpbmcgIkludGVyb3BlcmFiaWxpdHkgQ29uc2lkZXJhdGlvbnMiLCAiUHVibGlz aGVkIFNwZWNpZmljYXRpb24iLCAiQXBwbGljYXRpb25zIHRoYXQgdXNlIHRoaXMgbWVkaWEgdHlw ZSIsICJGcmFnbWVudCBpZGVudGlmaWVyIGNvbnNpZGVyYXRpb25zIiwgIkFkZGl0aW9uYWwgaW5m b3JtYXRpb24iICh3aGljaCBoYXMgZm91ciBzdWItZmllbGRzIiwgIkNvbnRhY3QgaW5mb3JtYXRp b24iLCAiSW50ZW5kZWQgVXNhZ2UiLCAiUmVzdHJpY3Rpb25zIE9uIFVzYWdlIiwgIkF1dGhvciIs IGFuZCAiQ2hhbmdlIENvbnRyb2xsZXIiLiAgUGxlYXNlIHNlZSBSRkMgNjgzOC4gIEZ1cnRoZXIs IGl0IHdvdWxkIHByb2JhYmx5IGJlIGEgZ29vZCBpZGVhIHRvIG1lbnRpb24gZWl0aGVyIGluIHRo ZSByZWdpc3RyYXRpb24gb3IgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIG9mIHRoaXMg ZG9jdW1lbnQgdGhhdCB0aGUgcGF5bG9hZCBiZWluZyByZWdpc3RlcmVkIGRvZXMgbm90IChvciBk b2VzKSBjb250YWluIGNvZGUgdGhhdCBpcyBleGVjdXRhYmxlLiAgVGhlIG1lZGlhIHR5cGUgcmV2 aWV3ZXJzIHByZWZlciBwZW9wbGUgdG8gYmUgZXhwbGljaXQgb24gdGhpcyBwb2ludC4NCg0KLU1T Sw0K --_000_PR3P192MB0748D48268FFC24A1BBE1DC4AC5B9PR3P192MB0748EURP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWst d29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ RGVhciBNdXJyYXksPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rIHlvdSBmb3IgdGhlIHJl dmlldy4gV2UgaGF2ZSBhZGRyZXNzZWQgeW91ciBjb21tZW50cyBpbiBkcmFmdC1pZXRmLXBheWxv YWQtcnRwLWpwZWd4cy0xMi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVyZSBpcyB0aGUgZGV0 YWlsZWQgYW5zd2VyIHRvIHRoZSBjb21tZW50czo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0 O0luIFNlY3Rpb24gMiwgcGxlYXNlIHVwZGF0ZSB0aGUgQkNQIDE0IHRleHQgdG8gdXNlIHRoZSBu ZXcgZm9ybSAoc2VlIFJGQyA4MTc0LCB3aGljaCBtdXN0IGFsc28gYmUgYWRkZWQgYXMgYSBub3Jt YXRpdmUgcmVmZXJlbmNlKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IFdlIGhhdmUg dXBkYXRlZCB0aGUgdGV4dCB0byBjb21wbHkgd2l0aCBSRkMgODE3NC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgQWxzbyBpbiBTZWN0 aW9uIDIsIHRoZSB0ZXJtICZxdW90O1NPQyBNYXJrZXImcXVvdDssIHRob3VnaCBkZWZpbmVkIGhl cmUsIGlzIG5vdCB1c2VkIGJlbG93IGhlcmUuJm5ic3A7IFNlY3Rpb24gMy4yIHJlZmVyZW5jZXMg dGhlIEVPQyBNYXJrZXI7IHNob3VsZCBpdCByZWZlcmVuY2UgYm90aD88bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7IDEpIFRoZSB0ZXJtICZxdW90O1NPQyBtYXJrZXImcXVvdDsgaXMgdXNl ZCBpbiBzZWN0aW9uIDIgdW5kZXIgJnF1b3Q7SlBFRyBYUyBjb2Rlc3RyZWFtIGhlYWRlciZxdW90 Oy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAyKSBXZSBjbGFy aWZpZWQgc2VjdGlvbiAzLjIsIHJlZmVyZW5jaW5nICZxdW90O1NPQyBtYXJrZXImcXVvdDsuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7 IEluIFNlY3Rpb24gNCwgd2UgZW5jb3VudGVyICZxdW90O1NTUkMmcXVvdDsgZm9yIHRoZSBmaXJz dCB0aW1lLiZuYnNwOyBBIGRlZmluaXRpb24gZm9yIGl0IHdvdWxkIGJlIGhlbHBmdWwsIG9yIGEg cmVmZXJlbmNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgU1NSQyBpcyBTeW5jaHJv bml6YXRpb24gU291cmNlLCBhcyBkZWZpbmVkIGluIFJGQzM1NTAuIFdlIG1vZGlmaWVkIHRoZSB0 ZXh0IHRvIGNsYXJpZnkgdGhpcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgSW4gU2VjdGlvbiA0LjIsICZxdW90O0FzIHBlciBzcGVj aWZpZWQmcXVvdDsgY2FuIGp1c3QgYmUgJnF1b3Q7QXMgc3BlY2lmaWVkJnF1b3Q7LiZuYnNwOyBB bHRlcm5hdGl2ZWx5LCAmcXVvdDtBcyBwZXIgUkZDIDM1NTAsIC4uLiZxdW90OyZuYnNwOyBXaGls ZSBJJ20gdGhpbmtpbmcgYWJvdXQgaXQsIGFsbCB0aGVzZSBkb3VibGUgcmVmZXJlbmNlcyAoZS5n LiwgJnF1b3Q7UkZDIDM1NTAgW1JGQzM1NTBdJnF1b3Q7KSB0aHJvdWdob3V0IHRoZSBkb2N1bWVu dCBjb3VsZCBiZSBjbGVhbmVkIHVwLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgV2Ug aGF2ZSBjbGVhbmVkIHVwIHRoZSAmcXVvdDtkb3VibGUgcmVmZXJlbmNlcyZxdW90OyB0aHJvdWdo b3V0IHRoZSB0ZXh0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jmd0OyBUaGUgZGlhZ3JhbXMgaW4gU2VjdGlvbiA0LjQgc2hvdyAoZXZlbnR1 YWxseSkgaG93IHRoZSBFT0MgbWFya2VyIGZpdHMgaW50byB0aGlzLCBidXQgbm90IHRoZSBTT0Mg bWFya2VyLiZuYnNwOyBTaG91bGQgdGhleT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 IFdlIGNsYXJpZmllZCB0aGF0IHRoZSBTT0MgbWFya2VyIGlzIHBhcnQgb2YgdGhlIEpQRUcgWFMg Y29kZXN0cmVhbSBoZWFkZXIuIFRoZSBsYXR0ZXIgaXMgY2xlYXJseSBtZW50aW9uZWQgaW4gdGhl IGRpYWdyYW1zLiBFeHBsaWNpdGx5IG1lbnRpb25pbmcgU09DIGluIHRoZSBkaWFncmFtcyB3b3Vs ZCBjbHV0dGVyIHRoZSBsYXlvdXQsIGFuZCB3b3VsZCBwcm9iYWJseSByZXF1aXJlIHRvIGV4cGxp Y2l0bHkgYWRkDQogdGhlIG90aGVyIG1hcmtlcnMgaW4gdGhlIGNvZGVzdHJlYW0gaGVhZGVyIGFz IHdlbGwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mZ3Q7IFNlY3Rpb24gNC41IHVzZXMgYSBTSE9VTEQuJm5ic3A7IFNIT1VMRCBsZWF2ZXMg dGhlIGltcGxlbWVudGVyIHdpdGggYSBjaG9pY2UsIHNvIGl0J3MgYSBnb29kIGlkZWEgdG8gaW5j bHVkZSBndWlkYW5jZSBhYm91dCB3aGVuIG9uZSBtaWdodCBsZWdpdGltYXRlbHkgZG8gc29tZXRo aW5nIG90aGVyIHRoYW4gd2hhdCB0aGUgU0hPVUxEIHNheXMgdG8gZG8uJm5ic3A7IE9yLCBpZiB0 aGVyZSBpc24ndCBhbnksIG1heWJlIHRoaXMNCiBvdWdodCB0byBiZSBhIFNIQUxMPzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgV2UgcmV3b3JkZWQgc2VjdGlvbiA0LjUgc2xpZ2h0bHku IFRoZSBtZXNzYWdlIGlzIHRoYXQgYWN0dWFsIHRyYWZmaWMgc2hhcGluZyBhbmQgdGltaW5nIGRl bGl2ZXJ5IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBhbmQgZG9l cyBub3QgaW5mbHVlbmNlIHRoZSBwYXlsb2FkIHBhY2tldGl6YXRpb24uIFdlIGFsc28gbW92ZWQg dGhlIHNlY3Rpb24gb25lIGxldmVsIHVwIChiZWNhbWUNCiBzZWN0aW9uIDUpLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBJbiBTZWN0 aW9uIDYuMSwgaXQncyBjbGVhciB3aGF0IGEgcmVjZWl2ZXIgd291bGQgZG8gd2l0aCBzb21lIG9m IHRoZSBvcHRpb25hbCBwYXJhbWV0ZXJzIHdoZW4gdGhleSBhcmUgYWJzZW50IChpLmUuLCBkZWZh dWx0cyBhcmUgY2xlYXIpLCBidXQgbm90IGluIGFsbCBjYXNlcy4mbmJzcDsgV2hhdCBjYW4gYSBy ZWNlaXZlciBzYWZlbHkgYXNzdW1lIGFib3V0ICZxdW90O2RlcHRoJnF1b3Q7LCAmcXVvdDt3aWR0 aCZxdW90Oywgb3IgJnF1b3Q7aGVpZ2h0JnF1b3Q7LCBmb3INCiBleGFtcGxlLCB3aGVuIG5vdCBz cGVjaWZpZWQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBXZSB0aG91Z2h0IHRoaXMg d2FzIGNsYXJpZmllZCBieSBzZWN0aW9uIDYuMi4xLiBOZXZlcnRoZWxlc3MsIHdlIGFkZGVkIGEg c2hvcnQgcGFyYWdyYXBoIGluIHNlY3Rpb24gNiAobm93IHNlY3Rpb24gNykuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEFsc28gb24g Ni4xLCB0aGlzIG1lZGlhIHR5cGUgcmVnaXN0cmF0aW9uIGlzIG1pc3NpbmcgcmVxdWlyZWQgZmll bGRzLCBpbmNsdWRpbmcgJnF1b3Q7SW50ZXJvcGVyYWJpbGl0eSBDb25zaWRlcmF0aW9ucyZxdW90 OywgJnF1b3Q7UHVibGlzaGVkIFNwZWNpZmljYXRpb24mcXVvdDssICZxdW90O0FwcGxpY2F0aW9u cyB0aGF0IHVzZSB0aGlzIG1lZGlhIHR5cGUmcXVvdDssICZxdW90O0ZyYWdtZW50IGlkZW50aWZp ZXIgY29uc2lkZXJhdGlvbnMmcXVvdDssICZxdW90O0FkZGl0aW9uYWwgaW5mb3JtYXRpb24mcXVv dDsNCiAod2hpY2ggaGFzIGZvdXIgc3ViLWZpZWxkcyZxdW90OywgJnF1b3Q7Q29udGFjdCBpbmZv cm1hdGlvbiZxdW90OywgJnF1b3Q7SW50ZW5kZWQgVXNhZ2UmcXVvdDssICZxdW90O1Jlc3RyaWN0 aW9ucyBPbiBVc2FnZSZxdW90OywgJnF1b3Q7QXV0aG9yJnF1b3Q7LCBhbmQgJnF1b3Q7Q2hhbmdl IENvbnRyb2xsZXImcXVvdDsuJm5ic3A7IFBsZWFzZSBzZWUgUkZDIDY4MzguJm5ic3A7IEZ1cnRo ZXIsIGl0IHdvdWxkIHByb2JhYmx5IGJlIGEgZ29vZCBpZGVhIHRvIG1lbnRpb24gZWl0aGVyIGlu IHRoZSByZWdpc3RyYXRpb24gb3IgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQogb2Yg dGhpcyBkb2N1bWVudCB0aGF0IHRoZSBwYXlsb2FkIGJlaW5nIHJlZ2lzdGVyZWQgZG9lcyBub3Qg KG9yIGRvZXMpIGNvbnRhaW4gY29kZSB0aGF0IGlzIGV4ZWN1dGFibGUuJm5ic3A7IFRoZSBtZWRp YSB0eXBlIHJldmlld2VycyBwcmVmZXIgcGVvcGxlIHRvIGJlIGV4cGxpY2l0IG9uIHRoaXMgcG9p bnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBXZSBoYXZlIHJld29ya2VkIHRoZSBt ZWRpYSB0eXBlIHJlZ2lzdHJhdGlvbiBzZWN0aW9uIHRvIGZvbGxvdyBSRkMgNjgzOCBhbmQgUkZD IDQ4NTUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBXZSBhZGRlZCB0aGUgbm90aW9u IHRoYXQgdGhlIHBheWxvYWQgZm9ybWF0IGFuZCB0aGUgSlBFRyBYUyBlbmNvZGluZyBkbyBOT1Qg Y29udGFpbiBleGVjdXRhYmxlIGNvZGUgKHRvIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBz ZWN0aW9uKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5LaW5kIHJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaW0gQnJ1eWxhbnRzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5G cm9tOjwvYj4gYXZ0ICZsdDthdnQtYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9m IDwvYj4NCk11cnJheSBTLiBLdWNoZXJhd3k8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5IDMgTWF5 IDIwMjEgMDY6MTY8YnI+DQo8Yj5Ubzo8L2I+IGF2dGNvcmVAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gW0FWVENPUkVdIEFEIFJldmlldyBvZiBkcmFmdC1pZXRmLXBheWxvYWQtcnRwLWpw ZWd4cy0xMTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSB0aGVyZSwgaGVyZSdzIG15IEFEIFJldmlldyBv ZiB0aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+UGVyIHRoZSBzaGVwaGVyZCB3cml0ZXVwLCBJIGhhdmUgcmVxdWVzdGVkIGEg cmV2aWV3IGJ5IHRoZSBTRFAgRGlyZWN0b3JhdGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZpcnN0OiBJbiB0aGUgc2hlcGhlcmQgd3JpdGV1 cCwgcGxlYXNlIGNvcnJlY3QgdGhlIHNwZWxsaW5nIG9mIG15IG5hbWUuJm5ic3A7IDotKSZuYnNw OyBBbHNvLCB3aGlsZSB3ZSdyZSBpbiB0aGVyZSwgcXVlc3Rpb24gKDEyKSBhc2tzIHdoYXQgcmV2 aWV3cyB3ZXJlIGRvbmUsIGJ1dCB0aGUgYW5zd2VyIHNpbXBseSBzYXlzIHRoYXQgdGhlIGRvY3Vt ZW50IGNvbnRhaW5zIGEgbWVkaWEgdHlwZSByZWdpc3RyYXRpb24sIHdoaWNoDQogZG9lc24ndCBy ZWFsbHkgYW5zd2VyIHRoZSBxdWVzdGlvbi4mbmJzcDsgV2VyZSBhbnkgb2YgdGhlIG1lZGlhIHR5 cGUgcmV2aWV3IHJlc291cmNlcyBhc2tlZCBmb3IgZmVlZGJhY2sgb24gdGhpcz8mbmJzcDsgTGF0 ZXIgb24gdGhlIHNoZXBoZXJkIHNheXMgaGUgcmV2aWV3ZWQgaXQsIGJ1dCBpdCBkb2Vzbid0IHNh eSB3aGF0IG9mZmljaWFsIHJldmlld3MgbWF5IGhhdmUgYmVlbiB1bmRlcnRha2VuLiZuYnNwOyBB cyB5b3UgY2FuIHNlZSBsYXRlciBvbiwgdGhlcmUncyBhDQogZ29vZCBjaHVuayBvZiB0aGUgcmVn aXN0cmF0aW9uIG1pc3NpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkluIFNlY3Rpb24gMiwgcGxlYXNlIHVwZGF0ZSB0aGUgQkNQIDE0IHRl eHQgdG8gdXNlIHRoZSBuZXcgZm9ybSAoc2VlIFJGQyA4MTc0LCB3aGljaCBtdXN0IGFsc28gYmUg YWRkZWQgYXMgYSBub3JtYXRpdmUgcmVmZXJlbmNlKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbyBpbiBTZWN0aW9uIDIsIHRoZSB0ZXJt ICZxdW90O1NPQyBNYXJrZXImcXVvdDssIHRob3VnaCBkZWZpbmVkIGhlcmUsIGlzIG5vdCB1c2Vk IGJlbG93IGhlcmUuJm5ic3A7IFNlY3Rpb24gMy4yIHJlZmVyZW5jZXMgdGhlIEVPQyBNYXJrZXI7 IHNob3VsZCBpdCByZWZlcmVuY2UgYm90aD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gU2VjdGlvbiA0LCB3ZSBlbmNvdW50ZXIgJnF1b3Q7 U1NSQyZxdW90OyBmb3IgdGhlIGZpcnN0IHRpbWUuJm5ic3A7IEEgZGVmaW5pdGlvbiBmb3IgaXQg d291bGQgYmUgaGVscGZ1bCwgb3IgYSByZWZlcmVuY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIFNlY3Rpb24gNC4yLCAmcXVvdDtBcyBw ZXIgc3BlY2lmaWVkJnF1b3Q7IGNhbiBqdXN0IGJlICZxdW90O0FzIHNwZWNpZmllZCZxdW90Oy4m bmJzcDsgQWx0ZXJuYXRpdmVseSwgJnF1b3Q7QXMgcGVyIFJGQyAzNTUwLCAuLi4mcXVvdDsmbmJz cDsgV2hpbGUgSSdtIHRoaW5raW5nIGFib3V0IGl0LCBhbGwgdGhlc2UgZG91YmxlIHJlZmVyZW5j ZXMgKGUuZy4sICZxdW90O1JGQyAzNTUwIFtSRkMzNTUwXSZxdW90OykgdGhyb3VnaG91dCB0aGUg ZG9jdW1lbnQgY291bGQgYmUgY2xlYW5lZCB1cC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGRpYWdyYW1zIGluIFNlY3Rpb24gNC40IHNo b3cgKGV2ZW50dWFsbHkpIGhvdyB0aGUgRU9DIG1hcmtlciBmaXRzIGludG8gdGhpcywgYnV0IG5v dCB0aGUgU09DIG1hcmtlci4mbmJzcDsgU2hvdWxkIHRoZXk/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlY3Rpb24gNC41IHVzZXMgYSBTSE9V TEQuJm5ic3A7IFNIT1VMRCBsZWF2ZXMgdGhlIGltcGxlbWVudGVyIHdpdGggYSBjaG9pY2UsIHNv IGl0J3MgYSBnb29kIGlkZWEgdG8gaW5jbHVkZSBndWlkYW5jZSBhYm91dCB3aGVuIG9uZSBtaWdo dCBsZWdpdGltYXRlbHkgZG8gc29tZXRoaW5nIG90aGVyIHRoYW4gd2hhdCB0aGUgU0hPVUxEIHNh eXMgdG8gZG8uJm5ic3A7IE9yLCBpZiB0aGVyZSBpc24ndCBhbnksIG1heWJlIHRoaXMgb3VnaHQN CiB0byBiZSBhIFNIQUxMPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JbiBTZWN0aW9uIDYuMSwgaXQncyBjbGVhciB3aGF0IGEgcmVjZWl2ZXIg d291bGQgZG8gd2l0aCBzb21lIG9mIHRoZSBvcHRpb25hbCBwYXJhbWV0ZXJzIHdoZW4gdGhleSBh cmUgYWJzZW50IChpLmUuLCBkZWZhdWx0cyBhcmUgY2xlYXIpLCBidXQgbm90IGluIGFsbCBjYXNl cy4mbmJzcDsgV2hhdCBjYW4gYSByZWNlaXZlciBzYWZlbHkgYXNzdW1lIGFib3V0ICZxdW90O2Rl cHRoJnF1b3Q7LCAmcXVvdDt3aWR0aCZxdW90Oywgb3IgJnF1b3Q7aGVpZ2h0JnF1b3Q7LCBmb3IN CiBleGFtcGxlLCB3aGVuIG5vdCBzcGVjaWZpZWQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsc28gb24gNi4xLCB0aGlzIG1lZGlhIHR5cGUg cmVnaXN0cmF0aW9uIGlzIG1pc3NpbmcgcmVxdWlyZWQgZmllbGRzLCBpbmNsdWRpbmcgJnF1b3Q7 SW50ZXJvcGVyYWJpbGl0eSBDb25zaWRlcmF0aW9ucyZxdW90OywgJnF1b3Q7UHVibGlzaGVkIFNw ZWNpZmljYXRpb24mcXVvdDssICZxdW90O0FwcGxpY2F0aW9ucyB0aGF0IHVzZSB0aGlzIG1lZGlh IHR5cGUmcXVvdDssICZxdW90O0ZyYWdtZW50IGlkZW50aWZpZXIgY29uc2lkZXJhdGlvbnMmcXVv dDssICZxdW90O0FkZGl0aW9uYWwgaW5mb3JtYXRpb24mcXVvdDsNCiAod2hpY2ggaGFzIGZvdXIg c3ViLWZpZWxkcyZxdW90OywgJnF1b3Q7Q29udGFjdCBpbmZvcm1hdGlvbiZxdW90OywgJnF1b3Q7 SW50ZW5kZWQgVXNhZ2UmcXVvdDssICZxdW90O1Jlc3RyaWN0aW9ucyBPbiBVc2FnZSZxdW90Oywg JnF1b3Q7QXV0aG9yJnF1b3Q7LCBhbmQgJnF1b3Q7Q2hhbmdlIENvbnRyb2xsZXImcXVvdDsuJm5i c3A7IFBsZWFzZSBzZWUgUkZDIDY4MzguJm5ic3A7IEZ1cnRoZXIsIGl0IHdvdWxkIHByb2JhYmx5 IGJlIGEgZ29vZCBpZGVhIHRvIG1lbnRpb24gZWl0aGVyIGluIHRoZSByZWdpc3RyYXRpb24gb3Ig aW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQogb2YgdGhpcyBkb2N1bWVudCB0aGF0IHRo ZSBwYXlsb2FkIGJlaW5nIHJlZ2lzdGVyZWQgZG9lcyBub3QgKG9yIGRvZXMpIGNvbnRhaW4gY29k ZSB0aGF0IGlzIGV4ZWN1dGFibGUuJm5ic3A7IFRoZSBtZWRpYSB0eXBlIHJldmlld2VycyBwcmVm ZXIgcGVvcGxlIHRvIGJlIGV4cGxpY2l0IG9uIHRoaXMgcG9pbnQuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1NU0s8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_PR3P192MB0748D48268FFC24A1BBE1DC4AC5B9PR3P192MB0748EURP_-- From nobody Mon May 3 08:46:21 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88353A199E for ; Mon, 3 May 2021 08:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=intopix.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ye1DYleN95kW for ; Mon, 3 May 2021 08:46:13 -0700 (PDT) Received: from dispatch1-eu1.ppe-hosted.com (dispatch1-eu1.ppe-hosted.com [185.132.181.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 525723A19E1 for ; Mon, 3 May 2021 08:45:58 -0700 (PDT) X-Virus-Scanned: Proofpoint Essentials engine Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05lp2111.outbound.protection.outlook.com [104.47.17.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1-eu1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 77DBE40061; Mon, 3 May 2021 15:45:50 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PtLGBYQt3ThFpyxwA7+QVVwQQPOvfuMOaqzlytCmn9M5pB3XrW6fOGArPRk5tDzxMerg6W+hLut9fRxO4CVozPGeTee1sDIf+8CSE0KuQb9EjpzlkNWGHyGxFLrv4ixLKgB3+DeJTYaxP7iYiHGbJDn6VudUJmLkDqRcKHIvEQMVoQ060l2kTz3Rp85B4CuBgkxYTG8leYEjOzDEVSXoZhXkAIL+YuK0xOrQlvL2X14vwK7LxVCGNsMjdS4PgWsDrufQjtvUC5K6si+kHe44Po3AB4gl50efXDzraNw1h8V1iftHv1oQtR/8Ye9mejFddUt+6T6CEaU1ZqBtuUOLAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lULt548yV9wjeY1gpjPsYBGtQhRu/ZuH0A25QN1fJUU=; b=F/Ul+tie8/XURgdMkXFOeVq/EAqGxOsgO4bAP3jyR+bO2NlYLzdRcB4ZwdWVxwwCwGK+MoOxnrd302ONLhb2LjB62H4ckRf8r/Xh/0ILz+RVWGbRiyUOeYMGyeIJrjFKCN8sn0KhnRUmjZYIvb1H0Ch+fYQOy6Z6RGjo+AVDvU5I0IO1tr0QfEqR/y+zvj4dEwmBDFJRSNwBOp/6RRxjUul+vTV2BQsx8XsHEwkBLjKoiIFXLLZ1dTo1HMKpYsYMoiUuUz5s0lNRdE9FLQFvQcfXZi+6+TsaGrpg/pay9Nz90E0pUMQvoD092ZqBnCYbl8BOe2p1+QC8tcmOKq34FA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intopix.com; dmarc=pass action=none header.from=intopix.com; dkim=pass header.d=intopix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intopix.onmicrosoft.com; s=selector1-intopix-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lULt548yV9wjeY1gpjPsYBGtQhRu/ZuH0A25QN1fJUU=; b=DcUhWdhlGFJh+tjQ7TBadQ0Y6U68ioKKIzpwC8zqBa5FPBNJFUQV6bPbtPYs4caMiNxxj77ksRW+l2mtTsfCHJpyZ3b9DuVarRq33IsvzEVCrraUimBUOUdFpoVTYM02MfKZQDd5HPcktq0tSHpwoR6KsQMNiRPUGoeE9a/6UHw= Received: from PR3P192MB0748.EURP192.PROD.OUTLOOK.COM (2603:10a6:102:4f::24) by PR3P192MB0652.EURP192.PROD.OUTLOOK.COM (2603:10a6:102:4e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.38; Mon, 3 May 2021 15:45:48 +0000 Received: from PR3P192MB0748.EURP192.PROD.OUTLOOK.COM ([fe80::f598:e21e:5658:281f]) by PR3P192MB0748.EURP192.PROD.OUTLOOK.COM ([fe80::f598:e21e:5658:281f%5]) with mapi id 15.20.4087.044; Mon, 3 May 2021 15:45:48 +0000 From: Tim Bruylants To: "avt@ietf.org" CC: "Murray S. Kucherawy" Thread-Topic: AD Review of draft-ietf-payload-rtp-jpegxs-11 Thread-Index: AddAM1hwEKfJAjyMSXyWLwTtwpw56A== Date: Mon, 3 May 2021 15:45:48 +0000 Message-ID: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=intopix.com; x-originating-ip: [2a02:1810:1dbd:e901:9572:1c39:ee48:a399] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5befba44-b19c-4934-422f-08d90e4a85a3 x-ms-traffictypediagnostic: PR3P192MB0652: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vN7XquX/wA7WSyvM+NUI/fP1bfF8/S0mwYaPwu4IeNrcON3VthILnUpB206gOXn1hVwqauSKnM253x4X6zqazFAEv/Kia++mB+W+/y1PZpCzDV1ahiIkb87dDOWybo+cgaPbDzC2p6e6r9h87v9dUoudGosntIeUlU/XozmERARS1aEPLhA9k1fNWJox5TjNGNP98esc7urpJIEPWIKsUbHnM1kFgaSBk1N6SN8tsCRQQxRJ0qDRsa9IE1ZD0NVCuZAF2zqMZGJtWLAZQ29SRJB6kUUH/k8NXX9rhApJQrkS440IG2mzLE/7CQ31FOddGDlm3PZOQJnC0cqXH2FS9JDeuhtXABoxwL6pUOki0A1NMKboooUluoII3rWs6X2yzGj5bTRgfZWcRnetlcoztENhSror4DTtGnP3DW1G+9SKbieHahlIE8ELVnNnXI8bAq2ndisextB2Mw8GNmWWC5ZveEYQVvBfvXRXZ2daaJmWDbOS9cFdP4LyEnG376NUpz0Flm9FWhqrf8W47mwoebmXXYDsabg9dDndwuWNS+QjXTwTyrgDgC+7ZLjZ6aAqdXxDtA6w1KtpfOGLYAU3McZDnu9SivpchJbgP0DAea4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR3P192MB0748.EURP192.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(346002)(366004)(508600001)(66946007)(86362001)(71200400001)(6916009)(122000001)(53546011)(66556008)(66446008)(6506007)(52536014)(76116006)(83380400001)(33656002)(186003)(9686003)(38100700002)(7696005)(4326008)(5660300002)(8936002)(2906002)(55016002)(64756008)(66476007)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?K21aWWxhdEV0cCt6NFl5YXNRQkhjT0FzdFdwM0RxUjdTOGxyaTNpaEp6eG1J?= =?utf-8?B?MjhEdHpxdXFVWGhPUlFlcG5NQjdtaVRMUWNYdnlGSGh2ZlVpdkhZeWt5cFRw?= =?utf-8?B?WUVkMzFobnF0Sk51ZXF0dUxqVnBmck5sWm1lNzVnUlltYTh4cWVXaUJwQVFo?= =?utf-8?B?WStLb1hDeVpQQWkraXRCYkFuZ1h4UUREaVF1VStiUGRPbjhzQ2w0L1V1T1JX?= =?utf-8?B?QlVrN09vd1cwNmRTTFVUSjUyY09QbmlreC9ST2I3TnE2SG9mdGR5THEwbmpD?= =?utf-8?B?Szh2Y1dDcSs4dElDeWFBNFhCbCtPbk9KczQrQ0sxV2lhbVVGNmF0V25oZXpS?= =?utf-8?B?VTQ2SENvcEhsb0JjTUtTZ3BwUUlDOUxsbDFlMno1MkMwL3lWK3FVeXQ2R2pz?= =?utf-8?B?SjlTeDRIY0NMMU9Kc1lSTE1EcjR5MjRHYmZuSmZDaFFsblBrWWljVEUrMWRi?= =?utf-8?B?bVFqMklsTHptcWdheGs5WTJsYXhVemZ4dDdvcURYcFV3cU8yYThzLzE5amMv?= =?utf-8?B?aFM5QlBJakpQcmZ1aVdYcnIwZFBQemNRWEFlaEwxRkpTTTEyNGx5WGVBa2E3?= =?utf-8?B?Rmg4eklLR3JFSldnTzJlaG1hWU4zRGsvM3AxejhWMDBqN3hWT1VrV01udUcw?= =?utf-8?B?UmNYanF6eGY1UEFnNFkzbVI4QkJBREtVSUVIZ1FUY2U2UnZQWmc0bzNvdjZH?= =?utf-8?B?Ujc5UEN6cUtzU3dJcDJpMG00eDdocEJrSkZ6Q2RyT2dBWXQ4d3lFQkxNQnZK?= =?utf-8?B?cnpQTjg2R1RiSTZzZU5MOVplUzdFS24zekRDSU9VU3UyK0xMdjZqcm5ya21l?= =?utf-8?B?NkpaZE95aS85d1cyaWNjQUlNbXNiN2UyV1BYOUxRZmVYZ2lnS2FUb0hlTDI4?= =?utf-8?B?cUR1ZTlCUFd4aVZodk1wOU9iaUJwMFdpYjM3VC9mL3YwNVJFVmQ0UkhreWpu?= =?utf-8?B?cTNBUWVaVmJYMVZuS0VFRlJib201SmlhenUvL2FhUFoySGZMOG90S0J2aVJX?= =?utf-8?B?T3BzMHNSRld6RDlVeWU0UUx0ZEZrMmJ0bnVTT2gvUWF2a2p3alpFZ3RTK2g3?= =?utf-8?B?ekxKclkxZlNrblAzUFc1YThBWENYRVloSDBoZ3JNMVlYZmJRbGYvMDUyYTJJ?= =?utf-8?B?SU8rTW1lQ3E3Mi93NDJJVE5wc29wckwzK0lmaGVueHZvWkk2ZUZ1TUQzYThF?= =?utf-8?B?RnV2ZWhjUGpmcXVabFFDZ0RiTzFxU2Fmd3VXRHZUNE1JdysyTFFTeXpKbWV3?= =?utf-8?B?NWNuY00rNXJRYU1qSy9SYk9mODlGTjZCbFNadWZBNVE0SFRGMmZIYTdKV2lT?= =?utf-8?B?Q1FWcEpxRTRUTExDeTNKZE1IbEs1MXRNQW9OdlFNaDhGek5mQWZWNW8reG5E?= =?utf-8?B?b3lYWEozeTBEdldqbTZmSHBCK2NYOXNRL0FZYVlDTVh0R3V0NUZpcUpNMkFk?= =?utf-8?B?UlBWaVBGd0R2aG9qZEphSXZTOU1PNXQwZkp2NzdUTSsxSlFybi9rSXpyK1V1?= =?utf-8?B?MmxrOFFWSTM0ZFNpY2hoT2Q3NWRhN0pPaExhaGxhZnRrdHFneUs2RG9aWW8w?= =?utf-8?B?eWJPVGJ5c1lyN1MvRldoZXJUeHNyYmg3amdLSngvUGQvZ3JtdnBjaEwrNFNk?= =?utf-8?B?cHNrWm1qbFZVbVlGOVFUZWlia3BNVTJJdysrSVNlK2xsRFhiK0NvclJCYlJ2?= =?utf-8?B?ZDRIRWhsZmx0OXZqQUg2YXRBbnhaeU5kZTg2Q2tkNWVwY3grenhhSklWbUhI?= =?utf-8?B?SWhQTkk0ZGU0RTBjd1ExcDY4Q1dFSEcvMHV3TjR6VzI4WFhBSjQzSzVUYlk4?= =?utf-8?B?bUZMN1ZvanRnazh6SllEVmk4cTA5WFJ2UzhRWU03TlNzUkliS1B1WUV0OGEw?= =?utf-8?Q?V1loQvLxJTUO4?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_PR3P192MB074864360B953DA894A8F45BAC5B9PR3P192MB0748EURP_" MIME-Version: 1.0 X-OriginatorOrg: intopix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PR3P192MB0748.EURP192.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 5befba44-b19c-4934-422f-08d90e4a85a3 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2021 15:45:48.0301 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5f9168c7-cdac-4b23-9509-c278399e3c1f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ena4sLbxAFD+niO3Szd3dkuCJLAO6ZVuWAZCUaCCNtF0I9MzavAbRf/nx8gZylI3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3P192MB0652 X-MDID: 1620056751-O34x2vouSmBW Archived-At: Subject: [AVTCORE] AD Review of draft-ietf-payload-rtp-jpegxs-11 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 15:46:20 -0000 --_000_PR3P192MB074864360B953DA894A8F45BAC5B9PR3P192MB0748EURP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBNdXJyYXksDQoNClRoYW5rIHlvdSBmb3IgdGhlIHJldmlldy4gV2UgaGF2ZSBhZGRyZXNz ZWQgeW91ciBjb21tZW50cyBpbiBkcmFmdC1pZXRmLXBheWxvYWQtcnRwLWpwZWd4cy0xMi4NCg0K SGVyZSBpcyB0aGUgZGV0YWlsZWQgYW5zd2VyIHRvIHRoZSBjb21tZW50czoNCg0KPkluIFNlY3Rp b24gMiwgcGxlYXNlIHVwZGF0ZSB0aGUgQkNQIDE0IHRleHQgdG8gdXNlIHRoZSBuZXcgZm9ybSAo c2VlIFJGQyA4MTc0LCB3aGljaCBtdXN0IGFsc28gYmUgYWRkZWQgYXMgYSBub3JtYXRpdmUgcmVm ZXJlbmNlKS4NCg0KICBXZSBoYXZlIHVwZGF0ZWQgdGhlIHRleHQgdG8gY29tcGx5IHdpdGggUkZD IDgxNzQuDQoNCg0KDQo+IEFsc28gaW4gU2VjdGlvbiAyLCB0aGUgdGVybSAiU09DIE1hcmtlciIs IHRob3VnaCBkZWZpbmVkIGhlcmUsIGlzIG5vdCB1c2VkIGJlbG93IGhlcmUuICBTZWN0aW9uIDMu MiByZWZlcmVuY2VzIHRoZSBFT0MgTWFya2VyOyBzaG91bGQgaXQgcmVmZXJlbmNlIGJvdGg/DQoN CiAgMSkgVGhlIHRlcm0gIlNPQyBtYXJrZXIiIGlzIHVzZWQgaW4gc2VjdGlvbiAyIHVuZGVyICJK UEVHIFhTIGNvZGVzdHJlYW0gaGVhZGVyIi4NCiAgMikgV2UgY2xhcmlmaWVkIHNlY3Rpb24gMy4y LCByZWZlcmVuY2luZyAiU09DIG1hcmtlciIuDQoNCg0KDQo+IEluIFNlY3Rpb24gNCwgd2UgZW5j b3VudGVyICJTU1JDIiBmb3IgdGhlIGZpcnN0IHRpbWUuICBBIGRlZmluaXRpb24gZm9yIGl0IHdv dWxkIGJlIGhlbHBmdWwsIG9yIGEgcmVmZXJlbmNlLg0KDQogIFNTUkMgaXMgU3luY2hyb25pemF0 aW9uIFNvdXJjZSwgYXMgZGVmaW5lZCBpbiBSRkMzNTUwLiBXZSBtb2RpZmllZCB0aGUgdGV4dCB0 byBjbGFyaWZ5IHRoaXMuDQoNCg0KDQo+IEluIFNlY3Rpb24gNC4yLCAiQXMgcGVyIHNwZWNpZmll ZCIgY2FuIGp1c3QgYmUgIkFzIHNwZWNpZmllZCIuICBBbHRlcm5hdGl2ZWx5LCAiQXMgcGVyIFJG QyAzNTUwLCAuLi4iICBXaGlsZSBJJ20gdGhpbmtpbmcgYWJvdXQgaXQsIGFsbCB0aGVzZSBkb3Vi bGUgcmVmZXJlbmNlcyAoZS5nLiwgIlJGQyAzNTUwIFtSRkMzNTUwXSIpIHRocm91Z2hvdXQgdGhl IGRvY3VtZW50IGNvdWxkIGJlIGNsZWFuZWQgdXAuDQoNCiAgV2UgaGF2ZSBjbGVhbmVkIHVwIHRo ZSAiZG91YmxlIHJlZmVyZW5jZXMiIHRocm91Z2hvdXQgdGhlIHRleHQuDQoNCg0KDQo+IFRoZSBk aWFncmFtcyBpbiBTZWN0aW9uIDQuNCBzaG93IChldmVudHVhbGx5KSBob3cgdGhlIEVPQyBtYXJr ZXIgZml0cyBpbnRvIHRoaXMsIGJ1dCBub3QgdGhlIFNPQyBtYXJrZXIuICBTaG91bGQgdGhleT8N Cg0KICBXZSBjbGFyaWZpZWQgdGhhdCB0aGUgU09DIG1hcmtlciBpcyBwYXJ0IG9mIHRoZSBKUEVH IFhTIGNvZGVzdHJlYW0gaGVhZGVyLiBUaGUgbGF0dGVyIGlzIGNsZWFybHkgbWVudGlvbmVkIGlu IHRoZSBkaWFncmFtcy4gRXhwbGljaXRseSBtZW50aW9uaW5nIFNPQyBpbiB0aGUgZGlhZ3JhbXMg d291bGQgY2x1dHRlciB0aGUgbGF5b3V0LCBhbmQgd291bGQgcHJvYmFibHkgcmVxdWlyZSB0byBl eHBsaWNpdGx5IGFkZCB0aGUgb3RoZXIgbWFya2VycyBpbiB0aGUgY29kZXN0cmVhbSBoZWFkZXIg YXMgd2VsbC4NCg0KDQoNCj4gU2VjdGlvbiA0LjUgdXNlcyBhIFNIT1VMRC4gIFNIT1VMRCBsZWF2 ZXMgdGhlIGltcGxlbWVudGVyIHdpdGggYSBjaG9pY2UsIHNvIGl0J3MgYSBnb29kIGlkZWEgdG8g aW5jbHVkZSBndWlkYW5jZSBhYm91dCB3aGVuIG9uZSBtaWdodCBsZWdpdGltYXRlbHkgZG8gc29t ZXRoaW5nIG90aGVyIHRoYW4gd2hhdCB0aGUgU0hPVUxEIHNheXMgdG8gZG8uICBPciwgaWYgdGhl cmUgaXNuJ3QgYW55LCBtYXliZSB0aGlzIG91Z2h0IHRvIGJlIGEgU0hBTEw/DQoNCiAgV2UgcmV3 b3JkZWQgc2VjdGlvbiA0LjUgc2xpZ2h0bHkuIFRoZSBtZXNzYWdlIGlzIHRoYXQgYWN0dWFsIHRy YWZmaWMgc2hhcGluZyBhbmQgdGltaW5nIGRlbGl2ZXJ5IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9m IHRoaXMgc3BlY2lmaWNhdGlvbiBhbmQgZG9lcyBub3QgaW5mbHVlbmNlIHRoZSBwYXlsb2FkIHBh Y2tldGl6YXRpb24uIFdlIGFsc28gbW92ZWQgdGhlIHNlY3Rpb24gb25lIGxldmVsIHVwIChiZWNh bWUgc2VjdGlvbiA1KS4NCg0KDQoNCj4gSW4gU2VjdGlvbiA2LjEsIGl0J3MgY2xlYXIgd2hhdCBh IHJlY2VpdmVyIHdvdWxkIGRvIHdpdGggc29tZSBvZiB0aGUgb3B0aW9uYWwgcGFyYW1ldGVycyB3 aGVuIHRoZXkgYXJlIGFic2VudCAoaS5lLiwgZGVmYXVsdHMgYXJlIGNsZWFyKSwgYnV0IG5vdCBp biBhbGwgY2FzZXMuICBXaGF0IGNhbiBhIHJlY2VpdmVyIHNhZmVseSBhc3N1bWUgYWJvdXQgImRl cHRoIiwgIndpZHRoIiwgb3IgImhlaWdodCIsIGZvciBleGFtcGxlLCB3aGVuIG5vdCBzcGVjaWZp ZWQ/DQoNCiAgV2UgdGhvdWdodCB0aGlzIHdhcyBjbGFyaWZpZWQgYnkgc2VjdGlvbiA2LjIuMS4g TmV2ZXJ0aGVsZXNzLCB3ZSBhZGRlZCBhIHNob3J0IHBhcmFncmFwaCBpbiBzZWN0aW9uIDYgKG5v dyBzZWN0aW9uIDcpLg0KDQoNCg0KPiBBbHNvIG9uIDYuMSwgdGhpcyBtZWRpYSB0eXBlIHJlZ2lz dHJhdGlvbiBpcyBtaXNzaW5nIHJlcXVpcmVkIGZpZWxkcywgaW5jbHVkaW5nICJJbnRlcm9wZXJh YmlsaXR5IENvbnNpZGVyYXRpb25zIiwgIlB1Ymxpc2hlZCBTcGVjaWZpY2F0aW9uIiwgIkFwcGxp Y2F0aW9ucyB0aGF0IHVzZSB0aGlzIG1lZGlhIHR5cGUiLCAiRnJhZ21lbnQgaWRlbnRpZmllciBj b25zaWRlcmF0aW9ucyIsICJBZGRpdGlvbmFsIGluZm9ybWF0aW9uIiAod2hpY2ggaGFzIGZvdXIg c3ViLWZpZWxkcyIsICJDb250YWN0IGluZm9ybWF0aW9uIiwgIkludGVuZGVkIFVzYWdlIiwgIlJl c3RyaWN0aW9ucyBPbiBVc2FnZSIsICJBdXRob3IiLCBhbmQgIkNoYW5nZSBDb250cm9sbGVyIi4g IFBsZWFzZSBzZWUgUkZDIDY4MzguICBGdXJ0aGVyLCBpdCB3b3VsZCBwcm9iYWJseSBiZSBhIGdv b2QgaWRlYSB0byBtZW50aW9uIGVpdGhlciBpbiB0aGUgcmVnaXN0cmF0aW9uIG9yIGluIHRoZSBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucyBvZiB0aGlzIGRvY3VtZW50IHRoYXQgdGhlIHBheWxvYWQg YmVpbmcgcmVnaXN0ZXJlZCBkb2VzIG5vdCAob3IgZG9lcykgY29udGFpbiBjb2RlIHRoYXQgaXMg ZXhlY3V0YWJsZS4gIFRoZSBtZWRpYSB0eXBlIHJldmlld2VycyBwcmVmZXIgcGVvcGxlIHRvIGJl IGV4cGxpY2l0IG9uIHRoaXMgcG9pbnQuDQoNCiAgV2UgaGF2ZSByZXdvcmtlZCB0aGUgbWVkaWEg dHlwZSByZWdpc3RyYXRpb24gc2VjdGlvbiB0byBmb2xsb3cgUkZDIDY4MzggYW5kIFJGQyA0ODU1 Lg0KDQogIFdlIGFkZGVkIHRoZSBub3Rpb24gdGhhdCB0aGUgcGF5bG9hZCBmb3JtYXQgYW5kIHRo ZSBKUEVHIFhTIGVuY29kaW5nIGRvIE5PVCBjb250YWluIGV4ZWN1dGFibGUgY29kZSAodG8gdGhl IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24pLg0KDQoNCktpbmQgcmVnYXJkcywNClRp bSBCcnV5bGFudHMNCg0KDQoNCkZyb206IGF2dCA8YXZ0LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv OmF2dC1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIE11cnJheSBTLiBLdWNoZXJhd3kN ClNlbnQ6IE1vbmRheSAzIE1heSAyMDIxIDA2OjE2DQpUbzogYXZ0Y29yZUBpZXRmLm9yZzxtYWls dG86YXZ0Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFtBVlRDT1JFXSBBRCBSZXZpZXcgb2YgZHJh ZnQtaWV0Zi1wYXlsb2FkLXJ0cC1qcGVneHMtMTENCg0KSGkgdGhlcmUsIGhlcmUncyBteSBBRCBS ZXZpZXcgb2YgdGhpcyBkb2N1bWVudC4NClBlciB0aGUgc2hlcGhlcmQgd3JpdGV1cCwgSSBoYXZl IHJlcXVlc3RlZCBhIHJldmlldyBieSB0aGUgU0RQIERpcmVjdG9yYXRlLg0KDQpGaXJzdDogSW4g dGhlIHNoZXBoZXJkIHdyaXRldXAsIHBsZWFzZSBjb3JyZWN0IHRoZSBzcGVsbGluZyBvZiBteSBu YW1lLiAgOi0pICBBbHNvLCB3aGlsZSB3ZSdyZSBpbiB0aGVyZSwgcXVlc3Rpb24gKDEyKSBhc2tz IHdoYXQgcmV2aWV3cyB3ZXJlIGRvbmUsIGJ1dCB0aGUgYW5zd2VyIHNpbXBseSBzYXlzIHRoYXQg dGhlIGRvY3VtZW50IGNvbnRhaW5zIGEgbWVkaWEgdHlwZSByZWdpc3RyYXRpb24sIHdoaWNoIGRv ZXNuJ3QgcmVhbGx5IGFuc3dlciB0aGUgcXVlc3Rpb24uICBXZXJlIGFueSBvZiB0aGUgbWVkaWEg dHlwZSByZXZpZXcgcmVzb3VyY2VzIGFza2VkIGZvciBmZWVkYmFjayBvbiB0aGlzPyAgTGF0ZXIg b24gdGhlIHNoZXBoZXJkIHNheXMgaGUgcmV2aWV3ZWQgaXQsIGJ1dCBpdCBkb2Vzbid0IHNheSB3 aGF0IG9mZmljaWFsIHJldmlld3MgbWF5IGhhdmUgYmVlbiB1bmRlcnRha2VuLiAgQXMgeW91IGNh biBzZWUgbGF0ZXIgb24sIHRoZXJlJ3MgYSBnb29kIGNodW5rIG9mIHRoZSByZWdpc3RyYXRpb24g bWlzc2luZy4NCg0KSW4gU2VjdGlvbiAyLCBwbGVhc2UgdXBkYXRlIHRoZSBCQ1AgMTQgdGV4dCB0 byB1c2UgdGhlIG5ldyBmb3JtIChzZWUgUkZDIDgxNzQsIHdoaWNoIG11c3QgYWxzbyBiZSBhZGRl ZCBhcyBhIG5vcm1hdGl2ZSByZWZlcmVuY2UpLg0KDQpBbHNvIGluIFNlY3Rpb24gMiwgdGhlIHRl cm0gIlNPQyBNYXJrZXIiLCB0aG91Z2ggZGVmaW5lZCBoZXJlLCBpcyBub3QgdXNlZCBiZWxvdyBo ZXJlLiAgU2VjdGlvbiAzLjIgcmVmZXJlbmNlcyB0aGUgRU9DIE1hcmtlcjsgc2hvdWxkIGl0IHJl ZmVyZW5jZSBib3RoPw0KDQpJbiBTZWN0aW9uIDQsIHdlIGVuY291bnRlciAiU1NSQyIgZm9yIHRo ZSBmaXJzdCB0aW1lLiAgQSBkZWZpbml0aW9uIGZvciBpdCB3b3VsZCBiZSBoZWxwZnVsLCBvciBh IHJlZmVyZW5jZS4NCg0KSW4gU2VjdGlvbiA0LjIsICJBcyBwZXIgc3BlY2lmaWVkIiBjYW4ganVz dCBiZSAiQXMgc3BlY2lmaWVkIi4gIEFsdGVybmF0aXZlbHksICJBcyBwZXIgUkZDIDM1NTAsIC4u LiIgIFdoaWxlIEknbSB0aGlua2luZyBhYm91dCBpdCwgYWxsIHRoZXNlIGRvdWJsZSByZWZlcmVu Y2VzIChlLmcuLCAiUkZDIDM1NTAgW1JGQzM1NTBdIikgdGhyb3VnaG91dCB0aGUgZG9jdW1lbnQg Y291bGQgYmUgY2xlYW5lZCB1cC4NCg0KVGhlIGRpYWdyYW1zIGluIFNlY3Rpb24gNC40IHNob3cg KGV2ZW50dWFsbHkpIGhvdyB0aGUgRU9DIG1hcmtlciBmaXRzIGludG8gdGhpcywgYnV0IG5vdCB0 aGUgU09DIG1hcmtlci4gIFNob3VsZCB0aGV5Pw0KDQpTZWN0aW9uIDQuNSB1c2VzIGEgU0hPVUxE LiAgU0hPVUxEIGxlYXZlcyB0aGUgaW1wbGVtZW50ZXIgd2l0aCBhIGNob2ljZSwgc28gaXQncyBh IGdvb2QgaWRlYSB0byBpbmNsdWRlIGd1aWRhbmNlIGFib3V0IHdoZW4gb25lIG1pZ2h0IGxlZ2l0 aW1hdGVseSBkbyBzb21ldGhpbmcgb3RoZXIgdGhhbiB3aGF0IHRoZSBTSE9VTEQgc2F5cyB0byBk by4gIE9yLCBpZiB0aGVyZSBpc24ndCBhbnksIG1heWJlIHRoaXMgb3VnaHQgdG8gYmUgYSBTSEFM TD8NCg0KSW4gU2VjdGlvbiA2LjEsIGl0J3MgY2xlYXIgd2hhdCBhIHJlY2VpdmVyIHdvdWxkIGRv IHdpdGggc29tZSBvZiB0aGUgb3B0aW9uYWwgcGFyYW1ldGVycyB3aGVuIHRoZXkgYXJlIGFic2Vu dCAoaS5lLiwgZGVmYXVsdHMgYXJlIGNsZWFyKSwgYnV0IG5vdCBpbiBhbGwgY2FzZXMuICBXaGF0 IGNhbiBhIHJlY2VpdmVyIHNhZmVseSBhc3N1bWUgYWJvdXQgImRlcHRoIiwgIndpZHRoIiwgb3Ig ImhlaWdodCIsIGZvciBleGFtcGxlLCB3aGVuIG5vdCBzcGVjaWZpZWQ/DQoNCkFsc28gb24gNi4x LCB0aGlzIG1lZGlhIHR5cGUgcmVnaXN0cmF0aW9uIGlzIG1pc3NpbmcgcmVxdWlyZWQgZmllbGRz LCBpbmNsdWRpbmcgIkludGVyb3BlcmFiaWxpdHkgQ29uc2lkZXJhdGlvbnMiLCAiUHVibGlzaGVk IFNwZWNpZmljYXRpb24iLCAiQXBwbGljYXRpb25zIHRoYXQgdXNlIHRoaXMgbWVkaWEgdHlwZSIs ICJGcmFnbWVudCBpZGVudGlmaWVyIGNvbnNpZGVyYXRpb25zIiwgIkFkZGl0aW9uYWwgaW5mb3Jt YXRpb24iICh3aGljaCBoYXMgZm91ciBzdWItZmllbGRzIiwgIkNvbnRhY3QgaW5mb3JtYXRpb24i LCAiSW50ZW5kZWQgVXNhZ2UiLCAiUmVzdHJpY3Rpb25zIE9uIFVzYWdlIiwgIkF1dGhvciIsIGFu ZCAiQ2hhbmdlIENvbnRyb2xsZXIiLiAgUGxlYXNlIHNlZSBSRkMgNjgzOC4gIEZ1cnRoZXIsIGl0 IHdvdWxkIHByb2JhYmx5IGJlIGEgZ29vZCBpZGVhIHRvIG1lbnRpb24gZWl0aGVyIGluIHRoZSBy ZWdpc3RyYXRpb24gb3IgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIG9mIHRoaXMgZG9j dW1lbnQgdGhhdCB0aGUgcGF5bG9hZCBiZWluZyByZWdpc3RlcmVkIGRvZXMgbm90IChvciBkb2Vz KSBjb250YWluIGNvZGUgdGhhdCBpcyBleGVjdXRhYmxlLiAgVGhlIG1lZGlhIHR5cGUgcmV2aWV3 ZXJzIHByZWZlciBwZW9wbGUgdG8gYmUgZXhwbGljaXQgb24gdGhpcyBwb2ludC4NCg0KLU1TSw0K --_000_PR3P192MB074864360B953DA894A8F45BAC5B9PR3P192MB0748EURP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYx Mi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0id29yZC13 cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkRlYXIgTXVycmF5LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFuayB5b3Ug Zm9yIHRoZSByZXZpZXcuIFdlIGhhdmUgYWRkcmVzc2VkIHlvdXIgY29tbWVudHMgaW4gZHJhZnQt aWV0Zi1wYXlsb2FkLXJ0cC1qcGVneHMtMTIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlcmUg aXMgdGhlIGRldGFpbGVkIGFuc3dlciB0byB0aGUgY29tbWVudHM6PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZndDtJbiBTZWN0aW9uIDIsIHBsZWFzZSB1cGRhdGUgdGhlIEJDUCAxNCB0ZXh0IHRv IHVzZSB0aGUgbmV3IGZvcm0gKHNlZSBSRkMgODE3NCwgd2hpY2ggbXVzdCBhbHNvIGJlIGFkZGVk IGFzIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyBXZSBoYXZlIHVwZGF0ZWQgdGhlIHRleHQgdG8gY29tcGx5IHdpdGggUkZDIDgxNzQuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEFs c28gaW4gU2VjdGlvbiAyLCB0aGUgdGVybSAmcXVvdDtTT0MgTWFya2VyJnF1b3Q7LCB0aG91Z2gg ZGVmaW5lZCBoZXJlLCBpcyBub3QgdXNlZCBiZWxvdyBoZXJlLiZuYnNwOyBTZWN0aW9uIDMuMiBy ZWZlcmVuY2VzIHRoZSBFT0MgTWFya2VyOyBzaG91bGQgaXQgcmVmZXJlbmNlIGJvdGg/PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAxKSBUaGUgdGVybSAmcXVvdDtTT0MgbWFya2VyJnF1 b3Q7IGlzIHVzZWQgaW4gc2VjdGlvbiAyIHVuZGVyICZxdW90O0pQRUcgWFMgY29kZXN0cmVhbSBo ZWFkZXImcXVvdDsuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsg MikgV2UgY2xhcmlmaWVkIHNlY3Rpb24gMy4yLCByZWZlcmVuY2luZyAmcXVvdDtTT0MgbWFya2Vy JnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jmd0OyBJbiBTZWN0aW9uIDQsIHdlIGVuY291bnRlciAmcXVvdDtTU1JDJnF1b3Q7IGZv ciB0aGUgZmlyc3QgdGltZS4mbmJzcDsgQSBkZWZpbml0aW9uIGZvciBpdCB3b3VsZCBiZSBoZWxw ZnVsLCBvciBhIHJlZmVyZW5jZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IFNTUkMg aXMgU3luY2hyb25pemF0aW9uIFNvdXJjZSwgYXMgZGVmaW5lZCBpbiBSRkMzNTUwLiBXZSBtb2Rp ZmllZCB0aGUgdGV4dCB0byBjbGFyaWZ5IHRoaXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEluIFNlY3Rpb24gNC4yLCAmcXVvdDtB cyBwZXIgc3BlY2lmaWVkJnF1b3Q7IGNhbiBqdXN0IGJlICZxdW90O0FzIHNwZWNpZmllZCZxdW90 Oy4mbmJzcDsgQWx0ZXJuYXRpdmVseSwgJnF1b3Q7QXMgcGVyIFJGQyAzNTUwLCAuLi4mcXVvdDsm bmJzcDsgV2hpbGUgSSdtIHRoaW5raW5nIGFib3V0IGl0LCBhbGwgdGhlc2UgZG91YmxlIHJlZmVy ZW5jZXMgKGUuZy4sICZxdW90O1JGQyAzNTUwIFtSRkMzNTUwXSZxdW90OykgdGhyb3VnaG91dCB0 aGUgZG9jdW1lbnQgY291bGQgYmUgY2xlYW5lZCB1cC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7IFdlIGhhdmUgY2xlYW5lZCB1cCB0aGUgJnF1b3Q7ZG91YmxlIHJlZmVyZW5jZXMmcXVv dDsgdGhyb3VnaG91dCB0aGUgdGV4dC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgVGhlIGRpYWdyYW1zIGluIFNlY3Rpb24gNC40IHNo b3cgKGV2ZW50dWFsbHkpIGhvdyB0aGUgRU9DIG1hcmtlciBmaXRzIGludG8gdGhpcywgYnV0IG5v dCB0aGUgU09DIG1hcmtlci4mbmJzcDsgU2hvdWxkIHRoZXk/PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyBXZSBjbGFyaWZpZWQgdGhhdCB0aGUgU09DIG1hcmtlciBpcyBwYXJ0IG9mIHRo ZSBKUEVHIFhTIGNvZGVzdHJlYW0gaGVhZGVyLiBUaGUgbGF0dGVyIGlzIGNsZWFybHkgbWVudGlv bmVkIGluIHRoZSBkaWFncmFtcy4gRXhwbGljaXRseSBtZW50aW9uaW5nIFNPQyBpbiB0aGUgZGlh Z3JhbXMgd291bGQgY2x1dHRlciB0aGUgbGF5b3V0LCBhbmQgd291bGQgcHJvYmFibHkgcmVxdWly ZSB0byBleHBsaWNpdGx5IGFkZA0KIHRoZSBvdGhlciBtYXJrZXJzIGluIHRoZSBjb2Rlc3RyZWFt IGhlYWRlciBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jmd0OyBTZWN0aW9uIDQuNSB1c2VzIGEgU0hPVUxELiZuYnNwOyBTSE9V TEQgbGVhdmVzIHRoZSBpbXBsZW1lbnRlciB3aXRoIGEgY2hvaWNlLCBzbyBpdCdzIGEgZ29vZCBp ZGVhIHRvIGluY2x1ZGUgZ3VpZGFuY2UgYWJvdXQgd2hlbiBvbmUgbWlnaHQgbGVnaXRpbWF0ZWx5 IGRvIHNvbWV0aGluZyBvdGhlciB0aGFuIHdoYXQgdGhlIFNIT1VMRCBzYXlzIHRvIGRvLiZuYnNw OyBPciwgaWYgdGhlcmUgaXNuJ3QgYW55LCBtYXliZSB0aGlzDQogb3VnaHQgdG8gYmUgYSBTSEFM TD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IFdlIHJld29yZGVkIHNlY3Rpb24gNC41 IHNsaWdodGx5LiBUaGUgbWVzc2FnZSBpcyB0aGF0IGFjdHVhbCB0cmFmZmljIHNoYXBpbmcgYW5k IHRpbWluZyBkZWxpdmVyeSBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRp b24gYW5kIGRvZXMgbm90IGluZmx1ZW5jZSB0aGUgcGF5bG9hZCBwYWNrZXRpemF0aW9uLiBXZSBh bHNvIG1vdmVkIHRoZSBzZWN0aW9uIG9uZSBsZXZlbCB1cCAoYmVjYW1lDQogc2VjdGlvbiA1KS48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZn dDsgSW4gU2VjdGlvbiA2LjEsIGl0J3MgY2xlYXIgd2hhdCBhIHJlY2VpdmVyIHdvdWxkIGRvIHdp dGggc29tZSBvZiB0aGUgb3B0aW9uYWwgcGFyYW1ldGVycyB3aGVuIHRoZXkgYXJlIGFic2VudCAo aS5lLiwgZGVmYXVsdHMgYXJlIGNsZWFyKSwgYnV0IG5vdCBpbiBhbGwgY2FzZXMuJm5ic3A7IFdo YXQgY2FuIGEgcmVjZWl2ZXIgc2FmZWx5IGFzc3VtZSBhYm91dCAmcXVvdDtkZXB0aCZxdW90Oywg JnF1b3Q7d2lkdGgmcXVvdDssIG9yICZxdW90O2hlaWdodCZxdW90OywgZm9yDQogZXhhbXBsZSwg d2hlbiBub3Qgc3BlY2lmaWVkPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgV2UgdGhv dWdodCB0aGlzIHdhcyBjbGFyaWZpZWQgYnkgc2VjdGlvbiA2LjIuMS4gTmV2ZXJ0aGVsZXNzLCB3 ZSBhZGRlZCBhIHNob3J0IHBhcmFncmFwaCBpbiBzZWN0aW9uIDYgKG5vdyBzZWN0aW9uIDcpLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0 OyBBbHNvIG9uIDYuMSwgdGhpcyBtZWRpYSB0eXBlIHJlZ2lzdHJhdGlvbiBpcyBtaXNzaW5nIHJl cXVpcmVkIGZpZWxkcywgaW5jbHVkaW5nICZxdW90O0ludGVyb3BlcmFiaWxpdHkgQ29uc2lkZXJh dGlvbnMmcXVvdDssICZxdW90O1B1Ymxpc2hlZCBTcGVjaWZpY2F0aW9uJnF1b3Q7LCAmcXVvdDtB cHBsaWNhdGlvbnMgdGhhdCB1c2UgdGhpcyBtZWRpYSB0eXBlJnF1b3Q7LCAmcXVvdDtGcmFnbWVu dCBpZGVudGlmaWVyIGNvbnNpZGVyYXRpb25zJnF1b3Q7LCAmcXVvdDtBZGRpdGlvbmFsIGluZm9y bWF0aW9uJnF1b3Q7DQogKHdoaWNoIGhhcyBmb3VyIHN1Yi1maWVsZHMmcXVvdDssICZxdW90O0Nv bnRhY3QgaW5mb3JtYXRpb24mcXVvdDssICZxdW90O0ludGVuZGVkIFVzYWdlJnF1b3Q7LCAmcXVv dDtSZXN0cmljdGlvbnMgT24gVXNhZ2UmcXVvdDssICZxdW90O0F1dGhvciZxdW90OywgYW5kICZx dW90O0NoYW5nZSBDb250cm9sbGVyJnF1b3Q7LiZuYnNwOyBQbGVhc2Ugc2VlIFJGQyA2ODM4LiZu YnNwOyBGdXJ0aGVyLCBpdCB3b3VsZCBwcm9iYWJseSBiZSBhIGdvb2QgaWRlYSB0byBtZW50aW9u IGVpdGhlciBpbiB0aGUgcmVnaXN0cmF0aW9uIG9yIGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucw0KIG9mIHRoaXMgZG9jdW1lbnQgdGhhdCB0aGUgcGF5bG9hZCBiZWluZyByZWdpc3RlcmVk IGRvZXMgbm90IChvciBkb2VzKSBjb250YWluIGNvZGUgdGhhdCBpcyBleGVjdXRhYmxlLiZuYnNw OyBUaGUgbWVkaWEgdHlwZSByZXZpZXdlcnMgcHJlZmVyIHBlb3BsZSB0byBiZSBleHBsaWNpdCBv biB0aGlzIHBvaW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgV2UgaGF2ZSByZXdv cmtlZCB0aGUgbWVkaWEgdHlwZSByZWdpc3RyYXRpb24gc2VjdGlvbiB0byBmb2xsb3cgUkZDIDY4 MzggYW5kIFJGQyA0ODU1LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgV2UgYWRkZWQg dGhlIG5vdGlvbiB0aGF0IHRoZSBwYXlsb2FkIGZvcm1hdCBhbmQgdGhlIEpQRUcgWFMgZW5jb2Rp bmcgZG8gTk9UIGNvbnRhaW4gZXhlY3V0YWJsZSBjb2RlICh0byB0aGUgU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbnMgc2VjdGlvbikuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2luZCByZWdhcmRzLDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGltIEJydXlsYW50czxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+RnJvbTo8L2I+IGF2dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmF2dC1ib3VuY2VzQGll dGYub3JnIj5hdnQtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9i Pk11cnJheSBTLiBLdWNoZXJhd3k8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5IDMgTWF5IDIwMjEg MDY6MTY8YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzphdnRjb3JlQGlldGYub3JnIj5h dnRjb3JlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbQVZUQ09SRV0gQUQgUmV2 aWV3IG9mIGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtanBlZ3hzLTExPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PkhpIHRoZXJlLCBoZXJlJ3MgbXkgQUQgUmV2aWV3IG9mIHRoaXMgZG9jdW1lbnQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QZXIgdGhlIHNoZXBo ZXJkIHdyaXRldXAsIEkgaGF2ZSByZXF1ZXN0ZWQgYSByZXZpZXcgYnkgdGhlIFNEUCBEaXJlY3Rv cmF0ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Rmlyc3Q6IEluIHRoZSBzaGVwaGVyZCB3cml0ZXVwLCBwbGVhc2UgY29ycmVjdCB0aGUgc3Bl bGxpbmcgb2YgbXkgbmFtZS4mbmJzcDsgOi0pJm5ic3A7IEFsc28sIHdoaWxlIHdlJ3JlIGluIHRo ZXJlLCBxdWVzdGlvbiAoMTIpIGFza3Mgd2hhdCByZXZpZXdzIHdlcmUgZG9uZSwgYnV0IHRoZSBh bnN3ZXIgc2ltcGx5IHNheXMgdGhhdCB0aGUgZG9jdW1lbnQgY29udGFpbnMgYSBtZWRpYSB0eXBl IHJlZ2lzdHJhdGlvbiwgd2hpY2gNCiBkb2Vzbid0IHJlYWxseSBhbnN3ZXIgdGhlIHF1ZXN0aW9u LiZuYnNwOyBXZXJlIGFueSBvZiB0aGUgbWVkaWEgdHlwZSByZXZpZXcgcmVzb3VyY2VzIGFza2Vk IGZvciBmZWVkYmFjayBvbiB0aGlzPyZuYnNwOyBMYXRlciBvbiB0aGUgc2hlcGhlcmQgc2F5cyBo ZSByZXZpZXdlZCBpdCwgYnV0IGl0IGRvZXNuJ3Qgc2F5IHdoYXQgb2ZmaWNpYWwgcmV2aWV3cyBt YXkgaGF2ZSBiZWVuIHVuZGVydGFrZW4uJm5ic3A7IEFzIHlvdSBjYW4gc2VlIGxhdGVyIG9uLCB0 aGVyZSdzIGENCiBnb29kIGNodW5rIG9mIHRoZSByZWdpc3RyYXRpb24gbWlzc2luZy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gU2VjdGlv biAyLCBwbGVhc2UgdXBkYXRlIHRoZSBCQ1AgMTQgdGV4dCB0byB1c2UgdGhlIG5ldyBmb3JtIChz ZWUgUkZDIDgxNzQsIHdoaWNoIG11c3QgYWxzbyBiZSBhZGRlZCBhcyBhIG5vcm1hdGl2ZSByZWZl cmVuY2UpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5BbHNvIGluIFNlY3Rpb24gMiwgdGhlIHRlcm0gJnF1b3Q7U09DIE1hcmtlciZxdW90Oywg dGhvdWdoIGRlZmluZWQgaGVyZSwgaXMgbm90IHVzZWQgYmVsb3cgaGVyZS4mbmJzcDsgU2VjdGlv biAzLjIgcmVmZXJlbmNlcyB0aGUgRU9DIE1hcmtlcjsgc2hvdWxkIGl0IHJlZmVyZW5jZSBib3Ro PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J biBTZWN0aW9uIDQsIHdlIGVuY291bnRlciAmcXVvdDtTU1JDJnF1b3Q7IGZvciB0aGUgZmlyc3Qg dGltZS4mbmJzcDsgQSBkZWZpbml0aW9uIGZvciBpdCB3b3VsZCBiZSBoZWxwZnVsLCBvciBhIHJl ZmVyZW5jZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SW4gU2VjdGlvbiA0LjIsICZxdW90O0FzIHBlciBzcGVjaWZpZWQmcXVvdDsgY2FuIGp1 c3QgYmUgJnF1b3Q7QXMgc3BlY2lmaWVkJnF1b3Q7LiZuYnNwOyBBbHRlcm5hdGl2ZWx5LCAmcXVv dDtBcyBwZXIgUkZDIDM1NTAsIC4uLiZxdW90OyZuYnNwOyBXaGlsZSBJJ20gdGhpbmtpbmcgYWJv dXQgaXQsIGFsbCB0aGVzZSBkb3VibGUgcmVmZXJlbmNlcyAoZS5nLiwgJnF1b3Q7UkZDIDM1NTAg W1JGQzM1NTBdJnF1b3Q7KSB0aHJvdWdob3V0IHRoZSBkb2N1bWVudCBjb3VsZCBiZSBjbGVhbmVk IHVwLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGUgZGlhZ3JhbXMgaW4gU2VjdGlvbiA0LjQgc2hvdyAoZXZlbnR1YWxseSkgaG93IHRoZSBF T0MgbWFya2VyIGZpdHMgaW50byB0aGlzLCBidXQgbm90IHRoZSBTT0MgbWFya2VyLiZuYnNwOyBT aG91bGQgdGhleT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+U2VjdGlvbiA0LjUgdXNlcyBhIFNIT1VMRC4mbmJzcDsgU0hPVUxEIGxlYXZlcyB0 aGUgaW1wbGVtZW50ZXIgd2l0aCBhIGNob2ljZSwgc28gaXQncyBhIGdvb2QgaWRlYSB0byBpbmNs dWRlIGd1aWRhbmNlIGFib3V0IHdoZW4gb25lIG1pZ2h0IGxlZ2l0aW1hdGVseSBkbyBzb21ldGhp bmcgb3RoZXIgdGhhbiB3aGF0IHRoZSBTSE9VTEQgc2F5cyB0byBkby4mbmJzcDsgT3IsIGlmIHRo ZXJlIGlzbid0IGFueSwgbWF5YmUgdGhpcyBvdWdodA0KIHRvIGJlIGEgU0hBTEw/PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIFNlY3Rpb24g Ni4xLCBpdCdzIGNsZWFyIHdoYXQgYSByZWNlaXZlciB3b3VsZCBkbyB3aXRoIHNvbWUgb2YgdGhl IG9wdGlvbmFsIHBhcmFtZXRlcnMgd2hlbiB0aGV5IGFyZSBhYnNlbnQgKGkuZS4sIGRlZmF1bHRz IGFyZSBjbGVhciksIGJ1dCBub3QgaW4gYWxsIGNhc2VzLiZuYnNwOyBXaGF0IGNhbiBhIHJlY2Vp dmVyIHNhZmVseSBhc3N1bWUgYWJvdXQgJnF1b3Q7ZGVwdGgmcXVvdDssICZxdW90O3dpZHRoJnF1 b3Q7LCBvciAmcXVvdDtoZWlnaHQmcXVvdDssIGZvcg0KIGV4YW1wbGUsIHdoZW4gbm90IHNwZWNp ZmllZD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QWxzbyBvbiA2LjEsIHRoaXMgbWVkaWEgdHlwZSByZWdpc3RyYXRpb24gaXMgbWlzc2luZyBy ZXF1aXJlZCBmaWVsZHMsIGluY2x1ZGluZyAmcXVvdDtJbnRlcm9wZXJhYmlsaXR5IENvbnNpZGVy YXRpb25zJnF1b3Q7LCAmcXVvdDtQdWJsaXNoZWQgU3BlY2lmaWNhdGlvbiZxdW90OywgJnF1b3Q7 QXBwbGljYXRpb25zIHRoYXQgdXNlIHRoaXMgbWVkaWEgdHlwZSZxdW90OywgJnF1b3Q7RnJhZ21l bnQgaWRlbnRpZmllciBjb25zaWRlcmF0aW9ucyZxdW90OywgJnF1b3Q7QWRkaXRpb25hbCBpbmZv cm1hdGlvbiZxdW90Ow0KICh3aGljaCBoYXMgZm91ciBzdWItZmllbGRzJnF1b3Q7LCAmcXVvdDtD b250YWN0IGluZm9ybWF0aW9uJnF1b3Q7LCAmcXVvdDtJbnRlbmRlZCBVc2FnZSZxdW90OywgJnF1 b3Q7UmVzdHJpY3Rpb25zIE9uIFVzYWdlJnF1b3Q7LCAmcXVvdDtBdXRob3ImcXVvdDssIGFuZCAm cXVvdDtDaGFuZ2UgQ29udHJvbGxlciZxdW90Oy4mbmJzcDsgUGxlYXNlIHNlZSBSRkMgNjgzOC4m bmJzcDsgRnVydGhlciwgaXQgd291bGQgcHJvYmFibHkgYmUgYSBnb29kIGlkZWEgdG8gbWVudGlv biBlaXRoZXIgaW4gdGhlIHJlZ2lzdHJhdGlvbiBvciBpbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMNCiBvZiB0aGlzIGRvY3VtZW50IHRoYXQgdGhlIHBheWxvYWQgYmVpbmcgcmVnaXN0ZXJl ZCBkb2VzIG5vdCAob3IgZG9lcykgY29udGFpbiBjb2RlIHRoYXQgaXMgZXhlY3V0YWJsZS4mbmJz cDsgVGhlIG1lZGlhIHR5cGUgcmV2aWV3ZXJzIHByZWZlciBwZW9wbGUgdG8gYmUgZXhwbGljaXQg b24gdGhpcyBwb2ludC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+LU1TSzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_PR3P192MB074864360B953DA894A8F45BAC5B9PR3P192MB0748EURP_-- From nobody Mon May 3 09:58:28 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518BB3A1C47 for ; Mon, 3 May 2021 09:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvQNuNqmc01I for ; Mon, 3 May 2021 09:58:15 -0700 (PDT) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F5423A1CAF for ; Mon, 3 May 2021 09:58:11 -0700 (PDT) Received: by mail-vs1-xe33.google.com with SMTP id k19so3307183vsg.0 for ; Mon, 03 May 2021 09:58:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n1scRnvaiqJj3yznxjmLgXF/cor2YWm/OM92we5c7jY=; b=U5L9V5CkyXnYfNahTw2qYDP7AfPuAS5OR2nsxsrgn2bwxcKiqpL/hM7HomYMFqA+/T pVtT8w3U1QOWeY/P4ghdKtE5YT84l2pCcjLJ/yrB8ne2+8FliQP1/FZX7N73C3Z4JBue xHn+Wdn7O59dH+3JdNm/aAemmdSV/nq60WhXcMiYa6h4KQE8gf8uAjX0Ki0P8kDTRJIh TnEn7wYoYJu7R5B32kEsgWcoVF6+O29ZVj/zZc/CafbAwpJBu5ykvSB48Pewi78QAZBH 9jULhG0ym1rpXpOLFJkD+7TYlkgjDTzNvQnR4harMeT4xzzLpemL6c4PkbiGjkON1lUE ifWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n1scRnvaiqJj3yznxjmLgXF/cor2YWm/OM92we5c7jY=; b=EEdVto3Z/YNxaCIgW8JnU4g2fy1ImeTlWEU+YhjWzv2HVlKKEAckFYjC65dKrR8dij b9j0p7wFOkrxub/dR59FgInGggCeb//q+wtfwvzHyAK40plBLj69RF8lk0km7YTKyKzF CB36dgEazkm7PTWVllL0Awc9RLNPYGo9rDelcC9J2QhMkOaooz3RqKgjliK2XpFRs6oP 5d+ockZD2y8dZyQBd5Xn8ahDyZ/bzSMV0ywJZKJ9sFzFIXDH9q2FQ+edbSFjS07kj5Qm dJx4yOS1UqgkNUHG6DFaoPOOhdLAwZh7RnZiR5mnLy09W5/UPH+GZZoo1g1GO8UCl2KI 4kwQ== X-Gm-Message-State: AOAM533igaswQWhgNpxEG9KClbZIQQ/li63x/Vjs4aS391hGcBn239GK TOeWc8pa0RW5/x24E5dxEUEEbg2SPICtbUW97lM= X-Google-Smtp-Source: ABdhPJwtgt3elqjm8R61w933Y0LqfjSa3fWOYruk7Veu2pV7CDV48YrlBr7TxkYy3v/SNlfPExmAGBjjh96u6ymlKOs= X-Received: by 2002:a67:cc2:: with SMTP id 185mr17174061vsm.0.1620061089509; Mon, 03 May 2021 09:58:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Mon, 3 May 2021 09:57:58 -0700 Message-ID: To: Tim Bruylants Cc: "avtcore@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c1357c05c16fddaa" Archived-At: Subject: Re: [AVTCORE] AD Review of draft-ietf-payload-rtp-jpegxs-11 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 16:58:27 -0000 --000000000000c1357c05c16fddaa Content-Type: text/plain; charset="UTF-8" On Mon, May 3, 2021 at 7:57 AM Tim Bruylants wrote: > > Also in Section 2, the term "SOC Marker", though defined here, is not > used below here. Section 3.2 references the EOC Marker; should it > reference both? > > > > 1) The term "SOC marker" is used in section 2 under "JPEG XS codestream > header". > > 2) We clarified section 3.2, referencing "SOC marker". > Right, it was referenced in the Glossary that defines it, but not elsewhere. That seemed strange. > > In Section 4.2, "As per specified" can just be "As specified". > Alternatively, "As per RFC 3550, ..." While I'm thinking about it, all > these double references (e.g., "RFC 3550 [RFC3550]") throughout the > document could be cleaned up. > > > > We have cleaned up the "double references" throughout the text. > Thanks. The RFC Editor would probably have done the same, but now your AUTH48 might come a little sooner. > The diagrams in Section 4.4 show (eventually) how the EOC marker fits > into this, but not the SOC marker. Should they? > > > > We clarified that the SOC marker is part of the JPEG XS codestream > header. The latter is clearly mentioned in the diagrams. Explicitly > mentioning SOC in the diagrams would clutter the layout, and would probably > require to explicitly add the other markers in the codestream header as > well. > Fair enough. In my layperson's reading of the work, it was odd that the "end" marker was somehow worth mentioning explicitly but the "start" marker was being taken for granted. > > > In Section 6.1, it's clear what a receiver would do with some of the > optional parameters when they are absent (i.e., defaults are clear), but > not in all cases. What can a receiver safely assume about "depth", > "width", or "height", for example, when not specified? > > > > We thought this was clarified by section 6.2.1. Nevertheless, we added a > short paragraph in section 6 (now section 7). > > This could also be because I'm unfamiliar with the base work. It might be useful to mention in the registration that optional parameters are in fact overrides to metadata within the payload, since I think that's what you're telling me here. But that's not a blocker for starting Last Call. > Also on 6.1, this media type registration is missing required fields, > including "Interoperability Considerations", "Published Specification", > "Applications that use this media type", "Fragment identifier > considerations", "Additional information" (which has four sub-fields", > "Contact information", "Intended Usage", "Restrictions On Usage", "Author", > and "Change Controller". Please see RFC 6838. Further, it would probably > be a good idea to mention either in the registration or in the Security > Considerations of this document that the payload being registered does not > (or does) contain code that is executable. The media type reviewers prefer > people to be explicit on this point. > > > > We have reworked the media type registration section to follow RFC 6838 > and RFC 4855. > > > > We added the notion that the payload format and the JPEG XS encoding do > NOT contain executable code (to the Security Considerations section). > Great, thanks! I'll prepare the Last Call request now. -MSK --000000000000c1357c05c16fddaa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, May 3, 2021 at 7:57 AM Tim Bruyla= nts <TBR@intopix.com> wrote:
> Also in Sectio= n 2, the term "SOC Marker", though defined here, is not used belo= w here.=C2=A0 Section 3.2 references the EOC Marker; should it reference bo= th?

=C2=A0

=C2=A0 1) The term "SOC marker" is used in= section 2 under "JPEG XS codestream header".

=C2=A0 2) We clarified section 3.2, referencing &quo= t;SOC marker".


Right, = it was referenced in the Glossary that defines it, but not elsewhere.=C2=A0= That seemed strange.
=C2=A0

> In Section 4.2, "As per specified" ca= n just be "As specified".=C2=A0 Alternatively, "As per RFC 3= 550, ..."=C2=A0 While I'm thinking about it, all these double refe= rences (e.g., "RFC 3550 [RFC3550]") throughout the document could= be cleaned up.

=C2=A0

=C2=A0 We have cleaned up the "double reference= s" throughout the text.


Thanks.=C2=A0 The RFC Editor would probably have done the same, but now y= our AUTH48 might come a little sooner.

> The diagrams in Section 4.4 show (eventually) h= ow the EOC marker fits into this, but not the SOC marker.=C2=A0 Should they= ?

=C2=A0

=C2=A0 We clari= fied that the SOC marker is part of the JPEG XS codestream header. The latt= er is clearly mentioned in the diagrams. Explicitly mentioning SOC in the d= iagrams would clutter the layout, and would probably require to explicitly = add the other markers in the codestream header as well.


Fair enough.=C2=A0 In my layperson's reading = of the work, it was odd that the "end" marker was somehow worth m= entioning explicitly but the "start" marker was being taken for g= ranted.

=

=C2=A0

> In Section 6.1, it's clear what a receiver = would do with some of the optional parameters when they are absent (i.e., d= efaults are clear), but not in all cases.=C2=A0 What can a receiver safely = assume about "depth", "width", or "height", f= or example, when not specified?

=C2=A0

=C2=A0 We thought this was clarified by section 6.2.= 1. Nevertheless, we added a short paragraph in section 6 (now section 7).


<= div>This could also be because I'm unfamiliar with the base work.=C2=A0= It might be useful to mention in the registration that optional parameters= are in fact overrides to metadata within the payload, since I think that&#= 39;s what you're telling me here.=C2=A0 But that's not a blocker fo= r starting Last Call.

> Also on 6.1, this media type registration is missing required = fields, including "Interoperability Considerations", "Publis= hed Specification", "Applications that use this media type",= "Fragment identifier considerations", "Additional informati= on" (which has four sub-fields", "Contact information", "I= ntended Usage", "Restrictions On Usage", "Author",= and "Change Controller".=C2=A0 Please see RFC 6838.=C2=A0 Furthe= r, it would probably be a good idea to mention either in the registration o= r in the Security Considerations of this document that the payload being registered does not (or does) cont= ain code that is executable.=C2=A0 The media type reviewers prefer people t= o be explicit on this point.

=C2=A0

=C2=A0 We have reworked the media type registration = section to follow RFC 6838 and RFC 4855.

=C2=A0

=C2=A0 We added the notion that the payload format a= nd the JPEG XS encoding do NOT contain executable code (to the Security Con= siderations section).


Great, thanks!=C2=A0 I'll = prepare the Last Call request now.

-MSK
<= /div> --000000000000c1357c05c16fddaa-- From nobody Mon May 3 11:01:14 2021 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8EB3A1E95; Mon, 3 May 2021 11:01:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk CC: Ali Begen , avt@ietf.org, avtcore-chairs@ietf.org, bernard.aboba@gmail.com, draft-ietf-payload-rtp-jpegxs@ietf.org, superuser@gmail.com Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <162006487329.19690.2939110526682127858@ietfa.amsl.com> Date: Mon, 03 May 2021 11:01:13 -0700 Archived-At: Subject: [AVTCORE] Last Call: (RTP Payload Format for ISO/IEC 21122 (JPEG XS)) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 18:01:13 -0000 The IESG has received a request from the Audio/Video Transport Core Maintenance WG (avtcore) to consider the following document: - 'RTP Payload Format for ISO/IEC 21122 (JPEG XS)' 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-call@ietf.org mailing lists by 2021-05-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a Real-Time Transport Protocol (RTP) payload format to be used for transporting JPEG XS (ISO/IEC 21122) encoded video. JPEG XS is a low-latency, lightweight image coding system. Compared to an uncompressed video use case, it allows higher resolutions and frame rates, while offering visually lossless quality, reduced power consumption, and end-to-end latency confined to a fraction of a frame. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-jpegxs/ No IPR declarations have been submitted directly on this I-D. From nobody Mon May 3 12:38:33 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB643A0B5A for ; Mon, 3 May 2021 12:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_85yhCvbjvT for ; Mon, 3 May 2021 12:38:27 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 459073A0B5F for ; Mon, 3 May 2021 12:38:27 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id s25so8292363lji.0 for ; Mon, 03 May 2021 12:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=xBHMM+6rU5FbuKD1oXyG26vf4EirkZ3/PGRrCtk4aSM=; b=S3rakB2134AIUR4acjg8FNfMnsV31Tt5E4ElOqTXF5v3+5AVyHk4FFuPB6Ok/WI+LS RvZihDuf/xyMgKsmlIDlij1oF7H8SQDd0BxJk4mokq42Ht+5zeHMTfnLl+sE2D2m06rR Be42jUOwNzqX6nq/04aqEDmJE8DI+ORmmxeR8/NpUOZ+hYWgNYjQumgjBOfGjauFsHJV zxcoVolvIFMSPre12FqK/x7VIQfAZjMVeXNZFMRCTofDqoDkUXx9uYvgoJv1UYQyBVBj 3WSJr/X47mItOZh3AHavh/vjRsgZTsnTC6mpCL5B4gZ+aO/xPCGKW34BBQwrQSyhncXC xrNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xBHMM+6rU5FbuKD1oXyG26vf4EirkZ3/PGRrCtk4aSM=; b=h4xCi0FWKgmOGlyoNBJQcyzxN6pf7+s5/pXLxve8aFXd+EtGyzGFty7KpjbtmESpnq U6qyAYm36gT/ebWlNSVSXsazs7Im36UqycW0cQysLrrBUNQTeqeSAjO/hONya0KWYYt6 JJ9ewHs0V+p4gmHWYfZ3C98KaIpe1r4zyxz4cXy6jpYFKlc/tjXjBYXeQdG9YzU4luZP X7gIgE4r6giLe/02u8/TXnCugoqz+0klSrenbR6uo6tv5leac9xTcD2l0HM6RkDpxIVk DQkiTL5C45IcH20k/jsfAjCvFyJrORAoVSyfw+8Fk5imBNOm/3wpv82wNbo7cwFzaWuk BqeA== X-Gm-Message-State: AOAM531M2f7nK8YNh4mncW7juCkfoLh4TIWpeu91Gq7lIy490pFGUzeB UortEKhVtOvwPGQ2Ft5AVKqUZpWuRw9/hW9/koCPCG1xpZW73A== X-Google-Smtp-Source: ABdhPJzNZZ1BSj7b+tn5ES1tU54sy1fm0gtf54v3rdXHFQ6Cqup/rkc0bUbFJOp7YPDQ4BiSZ4eMV9Bsd9CJZAMDUYI= X-Received: by 2002:a2e:9f4d:: with SMTP id v13mr9404281ljk.413.1620070703578; Mon, 03 May 2021 12:38:23 -0700 (PDT) MIME-Version: 1.0 From: Bernard Aboba Date: Mon, 3 May 2021 12:38:14 -0700 Message-ID: To: IETF AVTCore WG Content-Type: multipart/alternative; boundary="000000000000cc421f05c1721af6" Archived-At: Subject: [AVTCORE] Call for Agenda Items: AVTCORE WG Virtual Interim X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 19:38:32 -0000 --000000000000cc421f05c1721af6 Content-Type: text/plain; charset="UTF-8" This is a call for Agenda Items for the AVTCORE WG virtual Interim on May 24, 2021 at 18:00 UTC. If you would like time on the agenda, please send email to the Chairs. Details of the meeting are available here: https://datatracker.ietf.org/meeting/interim-2021-avtcore-02/session/avtcore --000000000000cc421f05c1721af6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is a call for Agenda Items for the=C2=A0 AVTCORE WG v= irtual Interim on May 24, 2021 at 18:00 UTC.=C2=A0 If you would like time o= n the agenda, please send email to the Chairs.=C2=A0

--000000000000cc421f05c1721af6-- From nobody Wed May 5 20:41:53 2021 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A966E3A2E35; Wed, 5 May 2021 20:41:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Peter Yee via Datatracker To: Cc: avt@ietf.org, draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162027251164.6302.1747673550915835779@ietfa.amsl.com> Reply-To: Peter Yee Date: Wed, 05 May 2021 20:41:51 -0700 Archived-At: Subject: [AVTCORE] Genart last call review of draft-ietf-avtcore-multi-party-rtt-mix-14 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 03:41:52 -0000 Reviewer: Peter Yee Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-avtcore-multi-party-rtt-mix-14 Reviewer: Peter Yee Review Date: 2021-05-05 IETF LC End Date: 2021-05-03 IESG Telechat date: Not scheduled for a telechat Summary: This draft specifies updates to RFC 4103 to allow real-time text mixing for both multiparty-aware and multiparty-unaware participants. It has some minor issues that should be addressed before publication. [Ready with issues] Major issues: None Minor issues: Page 7, 1st block, 13th sentence: what constitutes a “reasonable effort”? It might be best to drop this sentence. Page 7, 2nd block, 2nd sentence, “300 ms”: would it make sense to append “period” or “timeout” after this value? Page 13, section 3.4, 2nd paragraph, 1st sentence: in regards to “only part”, how is this calculated? Page 15, section 3.12, 2nd paragraph, 1st sentence: The placing of all available redundant levels in the packet is presumably subject to a maximum packet size or the “CPS” limit, if there are obnoxious levels of redundancy specified? Page 17, section 3.17.2, 4th paragraph, 2nd sentence: “SHALL prefer” seems odd. It doesn’t say that the marking will actually be done. It’s just preferred. If you’re not going to require the marking in that sentence, then perhaps change “SHALL” to “SHOULD”. Page 19, section 3.20, 2nd paragraph, 2nd sentence: I don’t find the “something specific” particularly enlightening. Like what? An identifier for the method? Page 27, section 4.2.2, 4th paragraph: can you elaborate on these “Integrity considerations”? Otherwise, it’s difficult to comply with the SHALL in any meaningful way. Page 33, 3rd paragraph, 1st sentence: any reason for the change from “T.140” in the previous and following paragraphs to “t140” in this one? Page 33, 6th paragraph: how is disappearance determined? Page 35, section 11, 3rd paragraph, 2nd sentence before creating a new sentence (see nits, below): I’m having troubles tying the adjective “secure” to each of the nouns in the sentence. It works for “signaling” and perhaps “media”, but for “authentication”, one sort of assumes that authentication mechanism is secure and helping to provide the security. Perhaps you could reword that sentence? Nits/editorial comments: General: Change “multi-party” to “multiparty” throughout the document. While we are a bit inconsistent about that particular hyphenation within the IETF, all major dictionaries I sampled spell this as a single, non-hyphenated word. Append a comma after each instance of “e.g.”. Change “multiparty aware” to “multiparty-aware” throughout the document except in two cases where you “multiparty awareness”, which should be left alone. These are located in section 4.2, 1st paragraph, 1st sentence and section 6.1, 2nd paragraph, 2nd sentence. Change “fall-back” to “fallback” in a few places in the document. Both uses are found in the document. Change “RTP-mixer based” to “RTP-mixer-based” throughout the document. Change “multiparty capable” to “multiparty-capable” throughout the document. Delete periods at the end of section/subsection titles, e.g., section 6.2. Specific: Page 1, Abstract, 1st sentence: I’d rewrite it in the active voice as: “This document provides enhancements for RFC 4103 real-time text mixing suitable for a centralized conference model that enables source identification and rapidly interleaved transmission of text from different sources.” Page 1, Abstract, 3rd paragraph, 1st sentence: insert a hyphen between “multiparty” and “coded”. Page 5, 3rd paragraph, 1st sentence: I think I would change “in” to “at”. Page 5, 7th paragraph, 3rd sentence: delete “any”. Change “way” to “ways”. Page 6, section 1.1, 2nd paragraph: insert “are” before “as”. Page 6, section 1.1, “WebRTC” term: change “web based” to “web-based”. Insert “real-time” before “communication”. Page 6, “DTLS-SRTP” term: delete “stands for security”. Insert “is a DTLS extension for use with SRTP/SRTCP” before “specified”. Page 6, “multiparty-aware” term: change “stands for” to “describes”. Append a comma after “real-time” before “separated”. Append a comma after “source”. Page 6, “multiparty-unaware”: change “stands for” to “describes”. Pages 7 and 8: delete the period after each of the non-indented lines, e.g., at the end of “Multiple RTP streams, one per participant.” Page 7, 1st block, 4th sentence: change “end to end” to “end-to-end”. Page 7, 1st block, 11th sentence: append a comma after “participant”. Delete the following “and”. Insert “with” before “no”. Page 7, 1st block, 14th sentence: change “implementation” to “implementations” and delete “technologies” unless you really want the problem is in regards to technologies and not particular implementations. Page 7, 1st block 15th sentence: change “made” to “led to”. Insert “being” before “only”. Page 7, 2nd block, 1st sentence: insert “a” before “shorter”. Insert “the” before source”. Insert “the” before “CSRC”. Append field after “CSRC”. Page 7, 2nd block, 2nd sentence: insert “a” before the quoted “text/t140”. Page 7, 2nd block, 3rd sentence: delete the whole sentence. Page 7, 2nd block, 6th sentence: move “with” before “receivers”. Insert “having the” before “default”. Page 8, 1st partial block, 2nd full sentence: insert “it” before “corresponds”. Page 8, 1st full block, 6th sentence: change “be varying” to “vary”. Page 8, 1st full block, 9th sentence: change “while” to “When”. Page 9, section 1.3, 1st paragraph, 3rd sentence: change “calltaker” to “call taker”. Change “observing” to “to observe”. Page 11, section 2.4, 3rd paragraph: append a comma after “CSRC-list”. Page 12, section 3.1, 4th paragraph: change “From other aspects” to “In other regards”. Page 13, section 3.4, 1st paragraph, 3rd sentence: insert a hyphen between “10” and “second”. Page 13, section 3.4, 1st paragraph, 4th sentence: delete “a” before “good”. Page 13, section 3.4, 2nd paragraph, 1st sentence: insert “SHALL be” before “sent”. Insert “the” before “end”. Page 13, section 3.4, 2nd paragraph, 2nd sentence: Append a period at the end of the sentence. Page 13, section 3.4, 3rd paragraph: change “in” to “as”. Page 13, section 3.6: insert a hyphen between “locally” and “produced”. Append “text” after “produced”. Page 14, 1st paragraph, 3rd sentence: delete the comma after “T140blocks”. Page 14, section 3.10, 1st paragraph after the bullet points, 1st sentence: insert “the” before “time”. Page 15, section 3.11, 2nd paragraph: append a comma after “switch”. Change “poulated” to “populated”. Page 15, section 3.12, 1st paragraph, 1st sentence: insert “the” before “next”. Page 15, section 3.12, 1st paragraph, 2nd sentence: insert “the” before “next”. Page 15, section 3.12, 2nd paragraph, 2nd sentence: change “number” to “level”. Page 16, section 3.14, 1st paragraph, 1st sentence: delete an extraneous space after “(“. Page 16, section 3.14, 1st paragraph, last sentence: insert “self-sourced” before “data”. Delete “that it is source of itself”. Page 16, section 3.16, 1st paragraph, 1st sentence: append a comma after “CNAME”. Page 17, section 3.17.2, 1st paragraph, 1st sentence: insert “The receiver SHALL monitor”. Change “The” to “the”. Delete “SHALL be monitored”. Page 17, section 3.17.2, 2nd paragraph, 2nd sentence: append a comma after “case”. Insert “the receiver SHALL create” before “a t140block”. Delete “SHALL be created”. I’m suggesting but not certain that you might want to change “and assigned” to “associated with”. Page 17, section 3.17.2, 4th paragraph, 1st sentence: change “if” to “whether” if you are amenable to that wording. Page 18, 2nd paragraph: delete an extraneous blank line before this paragraph. Page 18, section 3.18, 1st sentence: insert a hyphen between “10” and “second”. Page 19, section 3.19, 1st sentence: insert “the” before “session”. Insert “the” before “media”. Page 19, section 3.19, 2nd sentence: insert “the” before “media”. Consider deleting “security by”. Page 19, section 3.19, 5th sentence: change “is” to “are”. Page 20, section 3.21, 4th sentence: append a period after “etc”. Page 21, 1st partial paragraph, 1st full sentence: insert “a” before “dropped”. Page 21, 1st full paragraph, 1st sentence: delete an extraneous space after “(“. Where the word “area” occurs, would that make more sense as “buffer” or “queue”? Page 21, 1st full paragraph, 2nd sentence: insert “initial” before the first “text”. Page 22, 1st paragraph, 2nd sentence: change “in” to “due to”. Page 22, 2nd paragraph, 1st sentence: insert “packets” before “103”. Delete the comma after “103”. Page 22, 2nd paragraph, 2nd sentence: there appears to be an adverb missing before “the”. Perhaps “during”? Page 22, 3rd paragraph, 2nd sentence: change “21040” to “21060”. Page 22, 4th paragraph, 1st sentence: change “needs” to “need”. Page 22, 4th paragraph, 2nd sentence: change “21150” to “21160”. Page 23, section 4, 1st paragraph, 2nd sentence: delete “and”. Page 23, section 4, 3rd paragraph: consider changing “of” before “the text” to “conveyed in”. Page 24, 1st full paragraph, 3rd sentence: insert “a” before “replacement”. Page 24, 1st full paragraph, 4th sentence: change “just” to “the same”. Page 26, section 4.2, 3rd paragraph, 2nd sentence: insert a hyphen between “best” and “effort”. Page 26, section 4.2, 4th paragraph, 1st sentence: append a comma after “simulated”. Page 26, section 4.2, 4th paragraph, 4th sentence: change “is depending” to “depends”. Page 26, section 4.2, 4th paragraph, 5th sentence: change “switch” to “switching”. Append a comma after “can”. Append a comma after “example”. Page 26, section 4.2.1, 3rd sentence: append a comma after “keep-alive”. Page 27, 5th bullet point: insert “the” before “next”. Change “if even” to “even if”. Insert “a” between “for” and “word delimiter”. Page 28, section 4.2.4, 1st paragraph: insert “the” before “UTF-8”. Change “transform” to “transformation”. Page 28, section 4.2.4, “BEL”: change the comma after “session” to a period. Capitalize “provides”. Page 28, section 4.2.4, “NEW LINE”, 3rd sentence: insert “the” before “display”. Page 28, section 4.2.4, “CR LF”, 1st sentence: delete the comma after “supported”. Page 28, section 4.2.4, “CR LF”, 3rd sentence: insert “the” before “display”. Page 28, section 4.2.4, “INT ESC”, 1st sentence: insert “the” before “mode”. Page 28, section 4.2.4, “SGR”, 2nd sentence: insert “the” before “rendition”. Page 29, 1st partial sentence: insert a hyphen between “256” and “bytes”. Then change “bytes” to “byte”. Page 29, “BOM”, 1st sentence: insert “it” before “SHALL”. Page 29, “Missing text mark”, 1st sentence: change the comma after “apostrophe ‘” to a period. Insert “It” before “marks”. Insert “the” before “place”. Insert “the” before “stream”. Page 29, “SGR”, 1st sentence: delete the comma after “(SGR)”. Insert “the” before “status”. Page 29, “SGR”, 2nd sentence: change “originated” to “originating”. Page 29, BS, last sentence: change “not” to “be”. Page 32, section 6.1, title: drop the “e.g.” in the subsection title. Page 32, section 6.1, 2nd paragraph, parenthetical: perhaps you want “i.e.,” instead of “e.g.” here given that further down you put “TTYS” in another parenthetical as though it weren’t just an example but the only exemplar of this type of device under discussion. Page 32, section 6.1, 2nd paragraph, last sentence: delete “make”. Change “adaptions” to “adapt”. Delete “for” before “the functional”. Delete “(TTY)”. Page 32, section 6.1, 3rd paragraph: delete “(TTYs)”. Page 33, 2nd paragraph, 2nd sentence: insert “a” before “two-way”. Page 33, 3rd paragraph, 2nd sentence: insert “the” before “NAME”. Page 33, section 7: insert a hyphen between “multiparty” and “mixing” in this one instance of that term. Other uses of the term in the document should not be hyphenated. Page 34, section 8, 1st paragraph: I like the sound of the sentence better if you swap “valid” and “also”. That’s just me.  Page 34, section 8, 3rd paragraph, 1st sentence: insert a space between “second” and “(“CPS”)”. Page 34, section 8, 3rd paragraph, 3rd sentence: insert “an” before “RTP”. Regarding “excess”: in excess of what? Page 35, section 11, 1st paragraph, 1st sentence: append a comma after “pack”. Page 35, section 11, 2nd paragraph, 1st sentence: append a comma after “CNAME”. Page 35, section 11, 3rd paragraph, 1st sentence: I suggest inserting “emitting” before “a continuous”. Change the comma after “flow of text” to a period. Delete the following “or”. Change the rest of that sentence to read something like: “They may also send text that appears to originate from other participants.” I rewrote that because the malicious participants don’t themselves masquerade as text, although that might be a mildly amusing Halloween costume. Page 35, section 11, 4th paragraph: delete one of “section” or “Section”. You capitalize that term interchangeably, so it’s your choice. Page 35, section 12.1 (when discussing -14 only): change “Cucherawy” to “Kucherawy” unless we’re talking about someone else. Yeah, I know these will all be deleted upon publication, but it caught my eye. I have not reviewed the remainder of the change history entries. From nobody Thu May 6 07:36:32 2021 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB743A2475; Thu, 6 May 2021 07:36:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rich Salz via Datatracker To: Cc: avt@ietf.org, draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162031178943.8783.4063437681950995450@ietfa.amsl.com> Reply-To: Rich Salz Date: Thu, 06 May 2021 07:36:29 -0700 Archived-At: Subject: [AVTCORE] Secdir last call review of draft-ietf-avtcore-multi-party-rtt-mix-16 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 14:36:30 -0000 Reviewer: Rich Salz Review result: Ready This review is for the benefit of the Security AD's. Nobody else should read this. Or, if you read it, treat it as any other last call review :) I know very little about WebRTC, AVT, etc. I thought Section 1.2, summary of the alternatives, was great. I wish more documents did this kind of thing. And similar for all of section 2. The details in Section 3 about how to comply seem very clear. If I were implementing this, I could use easily use this as a checklist and test suite. Section 3.19 is the most important one for transport security. Not knowing the operating environments, it seems reasonable. The security considerations seems a little scant, given the opportunity for privacy concerns of participants and for intruders to disrupt calls. Is it common that the mixer is a trusted entity? A statement on that either way would be useful. From nobody Thu May 6 09:49:28 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA443A28B4 for ; Thu, 6 May 2021 09:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.019 X-Spam-Level: X-Spam-Status: No, score=-4.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=onebbc.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TumefTy5mT5Y for ; Thu, 6 May 2021 09:49:22 -0700 (PDT) Received: from mailout1.cwwtf.bbc.co.uk (mailout1.cwwtf.bbc.co.uk [132.185.160.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 108FA3A28B1 for ; Thu, 6 May 2021 09:49:21 -0700 (PDT) Received: from BGB01XI1005.national.core.bbc.co.uk ([10.184.50.55]) by mailout1.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id 146GnKY7013977 for ; Thu, 6 May 2021 17:49:20 +0100 (BST) Received: from BGB01XH1004.national.core.bbc.co.uk (10.118.80.2) by BGB01XI1005.national.core.bbc.co.uk (10.184.50.55) with Microsoft SMTP Server (TLS) id 14.3.498.0; Thu, 6 May 2021 17:49:19 +0100 Received: from BGB01XH1003.national.core.bbc.co.uk (10.118.80.1) by BGB01XH1004.national.core.bbc.co.uk (10.118.80.2) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 6 May 2021 17:49:19 +0100 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (104.47.14.58) by BGB01XH1003.national.core.bbc.co.uk (172.22.64.33) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 6 May 2021 17:49:19 +0100 Received: from DB7PR01MB4667.eurprd01.prod.exchangelabs.com (2603:10a6:10:62::31) by DB9PR01MB7274.eurprd01.prod.exchangelabs.com (2603:10a6:10:21e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.27; Thu, 6 May 2021 16:49:18 +0000 Received: from DB7PR01MB4667.eurprd01.prod.exchangelabs.com ([fe80::cd:b844:977d:aea9]) by DB7PR01MB4667.eurprd01.prod.exchangelabs.com ([fe80::cd:b844:977d:aea9%4]) with mapi id 15.20.4087.044; Thu, 6 May 2021 16:49:18 +0000 From: James Barrett To: "avt@ietf.org" Thread-Topic: Request for comments on draft-weaver-pef-00 Thread-Index: AQHXQpfBA8Ws+pQFj0yzqr5Yi4EI1g== Date: Thu, 6 May 2021 16:49:17 +0000 Message-ID: <5FA3242D-6C23-442C-A398-085448644D14@bbc.co.uk> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.48.21041102 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=bbc.co.uk; x-originating-ip: [132.185.132.12] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7566e202-94a5-4481-3ad4-08d910aee3b2 x-ms-traffictypediagnostic: DB9PR01MB7274: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: i8bE9TTlakF+0B2H77zUBLqjnzp7+RRZnBOM/zAT6gUZydYCwokuiinq8hVG1GnrtYX3yoyqJ5+AeYNbtvn4aCPtqTwWtDc5yTT5a0Z15pBLeQHbRwuMh20mHec0C+Bo28YgCqpAuE2UVaWFRj5YbXD2qUYiJOpIYd02Brw04Ig/SyOylyiFEInEgjBXZMHcd2y7ITPMeYTmJK3CR5zYFWw80sqOYPJytcZhAdfb3Ei03CoRKtmqM38lwDblvLFSz73i0803HyKzsZ2f+d076XqxXtBKNkqdnVmpeL6RjV1lYrnb2wMqRjREK0b6Yxf/FBwdcmgdfAN6DdD3DVE7EnI9qSsHZP7SbWWGKEE1LSzbf+EsMlYU5viWBZ0E7R06eyXllEirp6G1HPP3z9BvXJ6PbHYqW0N00KfjIxQrT6SXHfzBV8OHkZpFUG+huEZLimAvMC1shjE4LepGZYsb0aikVumfxULKL3rqGv099GUGoXQDn0xEznVI0vpd/YB8gLeflFnvOPJ11B+DaJYsrSr5/NwI8gz6c+ViXZ9ZngNdTOuT7Bmazxmr2ipsKIg73Fq3Fb6WQcpsPKvGqQ+sJuDoGlbil+YQuV3Bevek+MIHdz5xDhbKcl6OeJ6lAdf2YLnK4nDfzp1y11NHmpmJERjofB//sexaWfaYc1n1ErMO+0UUEpglEnJkqoiUsqvgjpA+L9dlQf5eRKLXO3dV5NBwIz3un7FLo0kk6wPl3JI= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR01MB4667.eurprd01.prod.exchangelabs.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(346002)(136003)(39860400002)(396003)(34552001)(83380400001)(166002)(33656002)(316002)(2616005)(36756003)(5660300002)(66556008)(91956017)(6486002)(66446008)(66946007)(76116006)(64756008)(66476007)(86362001)(478600001)(71200400001)(966005)(6916009)(2906002)(26005)(9326002)(186003)(122000001)(38100700002)(8676002)(8936002)(6512007)(6506007)(4744005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?akt4VHR5eFRUczJzbmg1bGlUSStRL2pvNTBSR3JQdXh5REY1K1BRd0tvRlcr?= =?utf-8?B?aU9wa1hVVHJsY3B4SjQxV3BOOTk5a0ZlY2ZqK0g3S3l4QnBaU3N3ZytVdFl6?= =?utf-8?B?blRmeGI1V2dudmRrWlJTZEIwbE5iNVhWSm5PeWphWlJrbUdNbWxlRWgwLzl2?= =?utf-8?B?cGFqZlZEdDBBU010N08wOVB6bjd3d1BUMzFqRVdYL3ZCTE5zenBCdmNOa0hQ?= =?utf-8?B?K2RHTDU2VkkzN1llblM2RUNXbEFWNHdCUDdEN3ZXdTJQS2tJVU1QaHhFRDhp?= =?utf-8?B?cmF0cFZQRVp3YndBdlVSUnFnOUh3WldEcVljTXRqVDdpd1hpTGE1OE9rQ2Vp?= =?utf-8?B?VXVwMTVnSUVOUDJtWGlHdnd6cHF2RDJpdTdDQkpBOC9MNjJOZjNuRG81azFL?= =?utf-8?B?b2pkbzlGTTZuaVNHRjdkVFFweFF3ckp5UjJBZEt4WW1zNUhBbElVeUh2OUpI?= =?utf-8?B?YkowUE9vRnA0NmRNeHJYRGl6V0VMSk5HMmphOWRIQzB2c2plKzNvK2dDd1Js?= =?utf-8?B?aHdDa3hBNkp1Y0FNSjVxZGlCdCs3MWRlSmdrTTRhNHlSMU5iell3NlU3dmlK?= =?utf-8?B?MGlwZG1lQXVYelpQNUFyTGhZK2J6NGY2bkR2WC81WDd2Qm9xYy9LQWxNTnkz?= =?utf-8?B?eHZ1MUFpOUVuc1dhQmVFQ0lrTUNmbkwxcWh1MUhNNktScSsya1hYb20xalY5?= =?utf-8?B?WEkzRHFOVFQ5eDkxdWlNZG0wYlpTeXBTdVV5Tm1RaUpiL0pGNVdFNU9CMEVP?= =?utf-8?B?UUU5bDloT3o3KzlTUUlORnJqeW9LZ0VBWTU1YnVMZFlLU2Y4RWVPRUJSMVhL?= =?utf-8?B?OEp4MjdNL01YZGN4NTg4WlVFMzR4RDRtbWpONUc3NlA4aWRIYXRtVjJkcWpa?= =?utf-8?B?T0NFNVp3bzR1OUV1UDhObGdhNkZXc0l1ODBIQU9YS2VNTk5iaklRVnp3Uzd3?= =?utf-8?B?R0lydnYwUkVwUnJ2S3dhU1Y3Unh1c1ZlNFYzNzdNeXEvUVB0WFNwYWdVb3h4?= =?utf-8?B?clFEYWZoaEk4cTV5eGcvenFoUW02WFQ4a1NNL1lucFBHemF6eXpkdzBqMFp5?= =?utf-8?B?NWg2SDQ1UVJMK0IvRkR4cDNOM3E3aVMrVkRleHVGUlZwYnFvRVBrdC9NbXZW?= =?utf-8?B?UWVteFlDcm5xVkREWGM0ZXVYckVKSWVybWhsNmFQUDFNL0hoeUpJVEQ2bWhz?= =?utf-8?B?UFowSTBEVU81M2tzZ2JzajRtYTNzTWNxVHhJNlJyWnBORmZ2L3RpanZmb29H?= =?utf-8?B?OGM4c3FTT0xTRDJIeWpBV2VQNVNpaGhuSXltalNYYk1aNW9QdWIySlFoNWR6?= =?utf-8?B?OVBtL2Uyak5DQVNBUTdiUlZmcnppWGthM2V4N05HWUIycE13V2l2QW10eEdk?= =?utf-8?B?Y2M0ZjVKc2l0VWo3d2ZyQ3ZxSjhDcW83NEpjT3UyOEdKajdIOUx6UXBGWGtl?= =?utf-8?B?V2NmKzB4Y2U1NkdEb0dRVGZwMFhlNXdKM1h6STY3eFNhSndoNWVyKzhsWU1l?= =?utf-8?B?Syt1VHdDQUxueVNaY0hkMkwwdzRGa0Qzb296N2w4MTJHV1JlazFMTk5VK3pu?= =?utf-8?B?S3FyVjVyV1I0L0dMdmozWmtwNlNUVFN0anJTcTVZNGdFTXhXdkxsVS9JS3V2?= =?utf-8?B?TWJIMWVJRHBRclo2T2U3c3Y1bzNXSlNqRjZ0VXd1UG5URmt4blRRdm5Oelpw?= =?utf-8?B?V1E0ekR1dDl6eUFoYVgxM3pLSDFuZlptanBNL1krZWpjQUFvd21haDArWFZs?= =?utf-8?Q?OsY62Pt+7DOw0DaAR/Gkaa/Iq0DKjjo87sIxjwl?= x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C59EhKcdhw6gxArrn41mWo57srMlJVpaeIwzNBfygvuHe7Tbi2h+X30q44B2HRS+4D2D6PGoeZqiLDVfIZ7N1cHFrx4vnjvlRXppdCwCAfCJf6c9oZg5ozoZZYHnYAzQXtcxt2NmuhiVD/sq2OccLGoePH4NFYZURlT0jxVOEPpB3IQ/pyVQ7HsJ4r302+rRrrKLB5VA1pEnS4axScguocsJ2MFERW1a/WJD9m6E5KUfdSALyfTKv9QPA1eK8+lcbz2eIEJNgft9dkFC9pjpuqzlmP5Hz6fzhYCzeJ7Bu8gFeJ3SbdvMKnKPGczOONNcvG8tND4D/zTAkO/pR8NAgQ== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E7QYZsRWDXDwmALm4zVBJVNEZjM6n6+4tj/r3Ehn5lE=; b=fct0bzR5beRclc2O3qfCu6LB4Wpu0iw65Zrcor/r2056xrhA0BWrU1g/dDktwFKr6RUfkMiVEg5X0uoE/qdOqK2cEe3pMh1c/3fCiNGO84z9/2hPLBvyRrm/x1K7Vpo6YRO14DMtE/PGEj3p4gUtSSDjuWYQ7EljKOS/yQsz88h7zdnT/epfp6A5wHf81v/XwW4MXN6U08p5QyYaf5f0PfGPSsnR0EwhcU8YtvXT2SzmRHvoaZHZphXTMM4xlfZSNSgG6hb5dx5EUiM9MIbwIGjv+fpe7hLIWahDBGl5lH4bHZjUFueyEI9+i30KWJMR9EmfkKHU0cR/Pxk+YE3ntA== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=bbc.co.uk; dmarc=pass action=none header.from=bbc.co.uk; dkim=pass header.d=bbc.co.uk; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onebbc.onmicrosoft.com; s=selector2-onebbc-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E7QYZsRWDXDwmALm4zVBJVNEZjM6n6+4tj/r3Ehn5lE=; b=Hd8Mq2UDmghhiKLGw1xRpT5Ch+NfZXmgGaqzGbBVnlYOPsuQKBFi1xI8ujYoqgH9geXsAQ6fyRbOxs/wYqUO/0BfCogXGY8FfVtkIN9/pU6pjPlOVwwHulHVNLV8J9DibvhyvxWen9owZn+PFUt4Vhzm/F8x/9KBd1H+cFyqDBk= x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: DB7PR01MB4667.eurprd01.prod.exchangelabs.com x-ms-exchange-crosstenant-network-message-id: 7566e202-94a5-4481-3ad4-08d910aee3b2 x-ms-exchange-crosstenant-originalarrivaltime: 06 May 2021 16:49:17.9358 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 0e587133-568e-44d6-801d-2266bc52e5cf x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: N6X/OFo8kqVQZpbV/sN23UFc+TubmC76Ggn5VYCJApQ8oPxsgl6sxXM+BK9UgkOLKOJ0FVdDExTNlvbFIlzAXg== x-ms-exchange-transport-crosstenantheadersstamped: DB9PR01MB7274 Content-Type: multipart/alternative; boundary="_000_5FA3242D6C23442CA398085448644D14bbccouk_" MIME-Version: 1.0 X-OriginatorOrg: bbc.co.uk X-EXCLAIMER-MD-CONFIG: c91d45b2-6e10-4209-9543-d9970fac71b7 X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.6.1012-24052.007 X-TM-AS-Result: No-13.914600-8.000000-10 X-TMASE-MatchedRID: pbMVlh5iif9x9EmrVy1N/Pzu9Lw9C7fACt4iaV1DkENaW2Ktn+I8/guO 7ZRdSklGZR+8vUFM+QkI3/DifCshB7Q/gWi/bNdV5DSMPEZQAkP7RKDUj/7lwZ192/Q+IxW27/+ 9swuISRVLbeMXCgjtvX7W5bdwgnW8o5RUoF1j1rj1NV6ZtjddkvwGVtfL479aOoj9DXM40dJb6/ SbnJwGr85B/9LVe+0QGbbQdh/kTL8JG55i6ynXHPilM7nponT86tEkNTIMeQgML9Wb3Qh/hZjzL xYjuNCwjy9ZHqwNMuQDyQW19neyjC+JsPJdMSAFhDK4kXfgEbrKIGMaZvT027LLTvamG8BJo8WM kQWv6iUVR7DQWX/WkVlmYwhSwhAa0C1sQRfQzEE6XEE7Yhw4FsT/6lqhEk1E6yryyPViFzQZO8k 4g15vjRHnk2vCqytkrXeQ7OG2OUFObfzNAxjOQzY0d1CG6/kr+Mlk+yruFxOR55irv7lBJlgpWC bva+Mm X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--13.914600-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.6.1012-24052.007 Archived-At: Subject: [AVTCORE] Request for comments on draft-weaver-pef-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 16:49:27 -0000 --_000_5FA3242D6C23442CA398085448644D14bbccouk_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCknigJl2ZSBzdWJtaXR0ZWQgYSBkcmFmdCwgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtd2VhdmVyLXBlZi8gd2hpY2ggZGVzY3JpYmVzIGEgcGFja2luZyBmb3Jt YXQgZm9yIHVuY29tcHJlc3NlZCB2aWRlby4gSWYgdGhlcmXigJlzIGFueSBpbnRlcmVzdCBpbiB0 aGlzIHByb2dyZXNzaW5nIHRvd2FyZHMgUkZDIHN0YXR1cyB0aGVuIEkgYmVsaWV2ZSB0aGlzIHdv dWxkIGJlIHRoZSBjb3JyZWN0IHdvcmtpbmcgZ3JvdXAgZm9yIGl0LiBFaXRoZXIgd2F5IEnigJlt IG9wZW4gdG8gYW55IGNvbW1lbnRzIG9yIG9ic2VydmF0aW9ucyB0aGF0IHRoZXJlIG1pZ2h0IGJl IG9uIHRoaXMuDQoNCi0tDQpKYW1lcyBXZWF2ZXIgKG7DqSBCYXJyZXR0KSBbSGUvSGltXQ0KUHJv amVjdCBSZXNlYXJjaCBFbmdpbmVlciwNCkNsb3VkLWZpdCBGdW5jdGlvbnMgJiBGb3VuZGF0aW9u cywNCkJCQyBSJkQNCg0KRW1haWw6IGphbWVzLmJhcnJldHRAYmJjLmNvLnVrPG1haWx0bzpqYW1l cy5iYXJyZXR0QGJiYy5jby51az4NCkdpdGh1YjogQGphbWVzYmENCg== --_000_5FA3242D6C23442CA398085448644D14bbccouk_ Content-Type: text/html; charset="utf-8" Content-ID: <26B9A9AEE5161B41BC3B85670FF23F53@eurprd01.prod.exchangelabs.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ill1IEdvdGhpYyI7DQoJcGFub3Nl LTE6MiAxMSA0IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxp YnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6IlxAWXUgR290aGljIjsNCglwYW5vc2UtMToyIDExIDQgMCAwIDAgMCAwIDAgMDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5 NTRGNzIiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PknigJl2ZSBzdWJtaXR0ZWQgYSBkcmFmdCwgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtd2VhdmVyLXBlZi8iPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtd2VhdmVyLXBlZi88L2E+IHdoaWNoIGRlc2NyaWJlcyBhIHBhY2tpbmcg Zm9ybWF0IGZvciB1bmNvbXByZXNzZWQgdmlkZW8uIElmIHRoZXJl4oCZcyBhbnkgaW50ZXJlc3Qg aW4gdGhpcyBwcm9ncmVzc2luZyB0b3dhcmRzIFJGQyBzdGF0dXMgdGhlbiBJIGJlbGlldmUgdGhp cyB3b3VsZCBiZSB0aGUgY29ycmVjdCB3b3JraW5nIGdyb3VwIGZvciBpdC4gRWl0aGVyIHdheSBJ 4oCZbSBvcGVuDQogdG8gYW55IGNvbW1lbnRzIG9yIG9ic2VydmF0aW9ucyB0aGF0IHRoZXJlIG1p Z2h0IGJlIG9uIHRoaXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS08 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkphbWVzIFdlYXZlciAobsOpIEJh cnJldHQpIFtIZS9IaW1dPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Qcm9q ZWN0IFJlc2VhcmNoIEVuZ2luZWVyLCA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkNsb3VkLWZpdCBGdW5jdGlvbnMgJmFtcDsgRm91bmRhdGlvbnMsPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CQkMgUiZhbXA7RCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FbWFpbDogPGEgaHJlZj0ibWFpbHRvOmphbWVzLmJhcnJl dHRAYmJjLmNvLnVrIj48c3BhbiBzdHlsZT0iY29sb3I6IzA1NjNDMSI+amFtZXMuYmFycmV0dEBi YmMuY28udWs8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkdpdGh1YjogQGphbWVzYmE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_5FA3242D6C23442CA398085448644D14bbccouk_-- From nobody Thu May 6 10:49:04 2021 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C20953A2ABC; Thu, 6 May 2021 10:49:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley via Datatracker To: Cc: avt@ietf.org, draft-ietf-payload-rtp-jpegxs.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162032334274.10241.3586337784439040714@ietfa.amsl.com> Reply-To: Russ Housley Date: Thu, 06 May 2021 10:49:02 -0700 Archived-At: Subject: [AVTCORE] Genart last call review of draft-ietf-payload-rtp-jpegxs-12 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 17:49:03 -0000 Reviewer: Russ Housley Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-payload-rtp-jpegxs-12 Reviewer: Russ Housley Review Date: 2021-05-06 IETF LC End Date: 2021-05-17 IESG Telechat date: Unknown Summary: Almost Ready Major Concerns: Section 7.2.1: Does the SHALL related to [SMPTE-ST2110-10] only apply when TP=2110TPNL or TP=2110TPW? Please reword to be clear when this SHALL statement applies. Minor Concerns: Section 3.3: I do not have [ISO21122-2], and obviously an implementer will need that document. Can a bit more be said about "the profile" and "the level and sublevel used" without making this document too big? I am able to get a feel for the other things listed here from their names. Section 3.4: Can you please provide some explanation of the "frat field"? Nits: Section 3.2: I do not understand the the last sentence? Is it the same as: It represents sample values of a single image, without any interpretation relative to a colour space. Section 5: s/of ST 2110-21 do not /of [SMPTE-ST2110-21] do not / From nobody Thu May 6 14:14:20 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A592E3A320E; Thu, 6 May 2021 14:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCisobx60z5H; Thu, 6 May 2021 14:14:14 -0700 (PDT) Received: from smtp.egensajt.se (smtp.egensajt.se [194.68.80.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CFDA3A320D; Thu, 6 May 2021 14:14:13 -0700 (PDT) Received: from [192.168.2.137] (h77-53-37-81.cust.a3fiber.se [77.53.37.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id CDE3D20A0F; Thu, 6 May 2021 23:14:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1620335649; bh=65Vp3lqJOPwPf74+0lJS+83Bd1agaIt2BQr+f43DAkI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=R20w6LU7ofzI/g5Pz1MlJiRAoWviGTl5l03MFH05iO+cwobuZgJNLJ+/N9w3p94IR 8sAm1c0KsaDd1PE3nd8HseenDKNAMxQmuxbh8a+AYspBOrs+hTRc/RZXwF7ND/aPfC g9Yoi5z88BzlI++v8lXoCiTybBuSsX+kfISUd1Sk= To: Peter Yee , gen-art@ietf.org Cc: avt@ietf.org, draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org, last-call@ietf.org References: <162027251164.6302.1747673550915835779@ietfa.amsl.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <32ad9a53-3aec-0a0f-ce77-6a3a79603e91@ghaccess.se> Date: Thu, 6 May 2021 23:14:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <162027251164.6302.1747673550915835779@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: sv Archived-At: Subject: Re: [AVTCORE] Genart last call review of draft-ietf-avtcore-multi-party-rtt-mix-14 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 21:14:20 -0000 Thank you for the thorough review. Please see comments inline. I will split the answers, and start here with answers and change proposals for the minor issues: Den 2021-05-06 kl. 05:41, skrev Peter Yee via Datatracker: > Reviewer: Peter Yee > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-avtcore-multi-party-rtt-mix-14 > Reviewer: Peter Yee > Review Date: 2021-05-05 > IETF LC End Date: 2021-05-03 > IESG Telechat date: Not scheduled for a telechat > > Summary: This draft specifies updates to RFC 4103 to allow real-time text > mixing for both multiparty-aware and multiparty-unaware participants. It has > some minor issues that should be addressed before publication. [Ready with > issues] > > Major issues: None > > Minor issues: > > Page 7, 1st block, 13th sentence: what constitutes a “reasonable effort”? It > might be best to drop this sentence. [GH] This reason is important for the desicion on technology selection. I suggest a change from: "For best deployment opportunity, it should be possible to upgrade existing endpoint solutions to be multi-party aware with a reasonable effort." to "For best deployment opportunity, it should be feasible to upgrade existing endpoint solutions to become multiparty-aware." > > Page 7, 2nd block, 2nd sentence, “300 ms”: would it make sense to append > “period” or “timeout” after this value? [GH] I suggest to change from "every 300 ms." to "with 300 ms intervals." > > Page 13, section 3.4, 2nd paragraph, 1st sentence: in regards to “only part”, > how is this calculated? [GH] I suggest to change from "If the "CPS" value is reached, longer transmission intervals SHALL be applied and only part of the text queued for transmission sent at end of each transmission interval, until the transmission rate falls under the "CPS" value again." to "If the "CPS" value is reached, longer transmission intervals SHALL be applied and only as much of the text queued for transmission sent at end of each transmission interval that can be allowed without exceeding the "CPS" value, until the transmission rate falls under the "CPS" value again. Division of text for partial transmission MUST then be made at T140block borders. " > > Page 15, section 3.12, 2nd paragraph, 1st sentence: The placing of all > available redundant levels in the packet is presumably subject to a maximum > packet size or the “CPS” limit, if there are obnoxious levels of redundancy > specified? [GH] Thanks, a good observation. It is already covered in section 3.10, but it could be more emphasized there. In 3.12 we are only dealing with the redundancy, which must be possible to send and is not included in the "CPS" value. I suggest that the following part of 3.10 is improved from: "Redundant text SHALL also be included.  See Section 3.12" to; "Redundant text SHALL also be included, and the assessment of how much new text can be included within the maximum packet size MUST take into account that the redundancy has priority to be transmitted in its entirety.  See Section 3.12." > > Page 17, section 3.17.2, 4th paragraph, 2nd sentence: “SHALL prefer” seems odd. > It doesn’t say that the marking will actually be done. It’s just preferred. If > you’re not going to require the marking in that sentence, then perhaps change > “SHALL” to “SHOULD”. [GH] Agreed. Done as proposed. > > Page 19, section 3.20, 2nd paragraph, 2nd sentence: I don’t find the “something > specific” particularly enlightening. Like what? An identifier for the method? [GH] Proposed to be changed from: " In that case, the    SDP of the offer will include something specific for that method, and    an answer acknowledging the use of that method would accept it by    something specific included in the SDP." to: "In that case, the    SDP of the offer will include something specific for that method, e.g. an SDP attribute or another media format. An answer selecting the use of that method would accept it by    a corresponding acknowledgement included in the SDP." > > Page 27, section 4.2.2, 4th paragraph: can you elaborate on these “Integrity > considerations”? Otherwise, it’s difficult to comply with the SHALL in any > meaningful way. [GH] The sentence was inserted after discussions with emergency service providers, who had an example that it would be valuable to have a detailed personalized label of an emergency service agent shown to other agents while a less personal label should be used when sent to the calling users in emergency. The security aspects on the label are quite similar to the security aspects on the elements specified in RFC 4575. Its security aspects are specified in https://tools.ietf.org/html/rfc4575#section-8 You are right that that example contains mainly SHOULD and RECOMMENDED and no SHALL. I suggest changing: "Integrity considerations SHALL be taken when composing the label." to: "Information available to the mixer for composing the label may contain sensitive personal information that SHOULD not be revealed in sessions not securely authenticated and protected. Integrity considerations regarding how much personal information is included in the label SHOULD therefore be taken when composing the label." > > Page 33, 3rd paragraph, 1st sentence: any reason for the change from “T.140” in > the previous and following paragraphs to “t140” in this one? [GH] No, they should be "T.140 data channels" for all cases in that paragraph. I have changed. > > Page 33, 6th paragraph: how is disappearance determined? [GH]The disappearance may be signaled by the SIP conference system RFC 4353, RFC 4575 etc. as a conference notification if that system is used, or simply by removal of the text media in an RTP session modification. There may also be a malfunction detected by keep-alive transactions not being maintained. I suggest to not detail how it disappears. > > Page 35, section 11, 3rd paragraph, 2nd sentence before creating a new sentence > (see nits, below): I’m having troubles tying the adjective “secure” to each of > the nouns in the sentence. It works for “signaling” and perhaps “media”, but > for “authentication”, one sort of assumes that authentication mechanism is > secure and helping to provide the security. Perhaps you could reword that > sentence? [GH] I propose to change the sentence from: "Counteractions should be to require    secure signaling, media and authentication, and to provide higher    level conference functions e.g. for blocking and expelling    participants." to: "Counteractions should be to require authentication, secure session signaling and secure media. Higher level conference functions should also be used e.g., for blocking and expelling participants who caused security concerns." Thanks, Gunnar Hellstrom -- Gunnar Hellström GHAccess gunnar.hellstrom@ghaccess.se From nobody Fri May 7 05:55:15 2021 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E45F3A2027; Fri, 7 May 2021 05:55:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: avt@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: avt@ietf.org Message-ID: <162039210907.16424.17598885622369958873@ietfa.amsl.com> Date: Fri, 07 May 2021 05:55:09 -0700 Archived-At: Subject: [AVTCORE] I-D Action: draft-ietf-payload-rtp-jpegxs-13.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2021 12:55:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance WG of the IETF. Title : RTP Payload Format for ISO/IEC 21122 (JPEG XS) Authors : Sébastien Lugan Antonin Descampe Corentin Damman Thomas Richter Tim Bruylants Filename : draft-ietf-payload-rtp-jpegxs-13.txt Pages : 30 Date : 2021-05-07 Abstract: This document specifies a Real-Time Transport Protocol (RTP) payload format to be used for transporting JPEG XS (ISO/IEC 21122) encoded video. JPEG XS is a low-latency, lightweight image coding system. Compared to an uncompressed video use case, it allows higher resolutions and frame rates, while offering visually lossless quality, reduced power consumption, and end-to-end latency confined to a fraction of a frame. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-jpegxs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-payload-rtp-jpegxs-13 https://datatracker.ietf.org/doc/html/draft-ietf-payload-rtp-jpegxs-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-jpegxs-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 7 05:59:49 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B983A2026; Fri, 7 May 2021 05:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=intopix.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQPnmvd45dzg; Fri, 7 May 2021 05:59:43 -0700 (PDT) Received: from dispatchb-eu1.ppe-hosted.com (dispatchb-eu1.ppe-hosted.com [185.132.181.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A0693A2039; Fri, 7 May 2021 05:59:39 -0700 (PDT) X-Virus-Scanned: Proofpoint Essentials engine Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04lp2054.outbound.protection.outlook.com [104.47.13.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1-eu1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 95BAE9C007F; Fri, 7 May 2021 12:59:36 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WAFhnimEl5EBa0DMD1TWqVWkqCnhPuYxXupbfKpcUx8bbAhxH9ZK0ijJI4F8Wgfun9Fa9s5CyE27iR+mN8Eep+R1VlkGv/YL8DlUDoL7iF8vZa4XVd8sNAhWj38GegZRs/VhP30Zm71yp9I9tyZ8WNS3IKzws860guEFo0Se+EtJUf9Sz0wZDqGFA/X82NZc738rqq7zmH342vCI5zw60afxTTzyvt6CZW3S0BW6Gi911eecgvP1i0AyNgqP666DTi4JFMRZ6ZlBj3ayKo9yh8A/nxy0sxQiYSp7AXXcYXmAREG9hifmpxzfw5MriPipd3JNxCv+p38Yb9GYCwoAKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l0ECw3uKfaZU7WWRRN5LcuUzZZe0QlmIZW+Gmvtd7cE=; b=WvWEWJdm6KNnceAnwpJf93X/IEK/SMjpIUUtrDVS0cE7Hx3cojAN9n0nA952BVmLM6SnKHKMBKuZHhZvaWbu5yLX16gGHdh5r0YocNgL3BwyVe2pokU7qa+4GHyiU7E3hx975Ze5YNBXRhfUnTbiq1cuzYfc8vQ8Wv7N+zl84b+t4ZGE5eRYmRs6+B4Fb0moxtnXCXpHYAKi4X5aaUp5x+5GVtYNF9awR7x8chyDeSDcTh3o/MAIXo3Myn/F4mYfqmPU3/BXwLs8e56YV6VRHeYKigz/5faH1tE0qR4pH+Ti/phKFLVYBRRAc79YUXE/KZmrQxJmp2IVBOjYxgSqWA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intopix.com; dmarc=pass action=none header.from=intopix.com; dkim=pass header.d=intopix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intopix.onmicrosoft.com; s=selector1-intopix-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l0ECw3uKfaZU7WWRRN5LcuUzZZe0QlmIZW+Gmvtd7cE=; b=VgB043czZy1wGq1x4jNjjsoc61hg+UAteQ2KZ4DpdeuhCv/j9B/4v7eBg6JAv2AGIxewFLmZiL/6682LC/Ip/NrgkDyqIYfn1huTYvaRMLXReXQxr0M+/7pA40ykM8CowAQ4n0In0IuzlRuHUHqbVpZjeNyyKLdl5ZaW+23njGk= Received: from PR3P192MB0748.EURP192.PROD.OUTLOOK.COM (2603:10a6:102:4f::24) by PAXP192MB1167.EURP192.PROD.OUTLOOK.COM (2603:10a6:102:1a0::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.26; Fri, 7 May 2021 12:59:35 +0000 Received: from PR3P192MB0748.EURP192.PROD.OUTLOOK.COM ([fe80::f598:e21e:5658:281f]) by PR3P192MB0748.EURP192.PROD.OUTLOOK.COM ([fe80::f598:e21e:5658:281f%5]) with mapi id 15.20.4108.029; Fri, 7 May 2021 12:59:35 +0000 From: Tim Bruylants To: Russ Housley , "gen-art@ietf.org" CC: "last-call@ietf.org" , "avt@ietf.org" , "draft-ietf-payload-rtp-jpegxs.all@ietf.org" Thread-Topic: [AVTCORE] Genart last call review of draft-ietf-payload-rtp-jpegxs-12 Thread-Index: AQHXQqAhhZJS9EYjKEeou2Vs8Z5+zqrX+3iQ Date: Fri, 7 May 2021 12:59:35 +0000 Message-ID: References: <162032334274.10241.3586337784439040714@ietfa.amsl.com> In-Reply-To: <162032334274.10241.3586337784439040714@ietfa.amsl.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=intopix.com; x-originating-ip: [2a02:1810:1dbd:e901:989b:8cd0:4643:b603] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 46c6baf8-67a1-479c-1610-08d91157f6f9 x-ms-traffictypediagnostic: PAXP192MB1167: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5236; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sY46EoFKlWl30hi9xCr/iVcGi3IBB2lhgpX/W4IjuwXjoTAYnY4ODxpQsLamevveIUvh83miXHVvaS+u2i2eo2gQIX9VtgDDCYCTD0qyb5uSFFWt8HUVYusGrGCKDqpJeee9nlB149F/65I6WBg74plsmp42gfg0DDOfXaF2jUX43jWW6B/hmrYL4M9GB7xagyST/+URv2AiQZyCjfuL1iKFc6fMksaj1j/+lkjkWQ2WbxuXcDWuXaL/rFLSsjj098ibmflw1WlG95UbRv1pnFgJW0ExB0GmZYxGWioHYC87i2DMpPJuwd2IjUOjzq87rVhQNxwzqn40qChzv8T+gwss3POooqP4KIaXc2tJNUnuGhyDt+EEE38+At5owvgWkIATMu/okTKGIy2Pl/rMOoPZpG4wzwdqUEDYSM1zAPsYp09JQfzumjZi+xToPSfmaOBG7yRed1XxARiip8kjvFqcM/dpevaihPzKCnijQGoSZbxGsRTJnznpip2uBA1eo7ZIoe8jMk4gGoWydWkyE9n+yqbpbSKUEXTIJyaiAzFKdLXdqUtGjhhM4XRClpOfFumwWndciIyLiwJv0jAk/mqMtWPzYFZg+ejGHucOxlezePgvDWdZS2Un3FaoDSRE33C2k0RSX+gj0GyyeX4/ykB5/aIeCu7OlbZZSASHyV1jl7qgc9hWTinJPmd7w8/x x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR3P192MB0748.EURP192.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(39830400003)(376002)(396003)(346002)(366004)(136003)(66556008)(66446008)(64756008)(76116006)(66946007)(4326008)(122000001)(8676002)(71200400001)(66476007)(5660300002)(33656002)(38100700002)(6506007)(478600001)(55016002)(52536014)(7696005)(966005)(110136005)(316002)(54906003)(8936002)(53546011)(186003)(2906002)(86362001)(9686003)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?pPBiptWvimq9yQxOcmKs6M1x93LAwYqIKubSVo4qmJBud6VZm+/whsM2RuG/?= =?us-ascii?Q?49QiiSxOf+joofLyViR12DeSkRufJdQFfTVOSxtNcKmbA0qbDfakRgWfCPzI?= =?us-ascii?Q?00gbjDDaddXvzY+2O7gVFS2gGHghYZIsx2OU3H35/gcQAWZHFhkTMk51yS4H?= =?us-ascii?Q?oZnI6strynEx8QKXdksnmqNUmnvjCaJ8V8Wk3y8e4Uo+oTo0xWewZQkSfMs0?= =?us-ascii?Q?M5+sqMv8ep/FQ9tJYt8+Gj3kDvXVlzIRpS130NjgDDDZk+U7YEbnwG0Fi+mk?= =?us-ascii?Q?nsQLCZR3AQwb9vXBuM3KYCuZPUZBa6xIFelD7h08rGSpNT6owmiPt7iQpcJx?= =?us-ascii?Q?SZjFJ8w5C0eoJB49/xkwgRERMo1JIhYJ41QbkQzIGdBRuGKdeVn4laSzXVLa?= =?us-ascii?Q?Pmx3qH6H/U0yROfBBZpBc36aoTs2dHwKJ6Hwi5HsZ3fbbcZuu7Awqjf2tgQY?= =?us-ascii?Q?9kFPg13/x1XEdXgtdGhD1x0LinGEaSw5Liyt3AZoJ5bAKhlsNFxVksAPoe71?= =?us-ascii?Q?nT85+aVPClfDcFu3SJZYgZevTHtwMb+9RR33UG08zlWq6rQ7iAbdrsR/Ugu4?= =?us-ascii?Q?Hsxbx10pmH2S2ctaHhfsXEgLJUhvLeVloX5JDBPUobqO7qeVyHhK+cVFHvbT?= =?us-ascii?Q?yIQRd0+cu3cicCKTfI5Wzl7R5WzGs8TitwEaoDiOvV9QHORUibVUjJLCHpxZ?= =?us-ascii?Q?7E4aEMqYkGLN+B94FRZmGckCtZe+fHuIp7xQ3re3f7Br4HfXy+8IeQakU26O?= =?us-ascii?Q?SK3lbvZhSVGB0elLOnKGEtXuY+JvWBFb6LEK4/USrHwsBYyHkeDZCOXBaGF2?= =?us-ascii?Q?94XOuKX/k181sSig/BDFATqaUSk0J6VTsFi4V5yCdtCzPAI97EVogq6p6pSn?= =?us-ascii?Q?AHmnm7dHQiBy8ICgDh84TpNzWpZXekHNVl5Kgpue3iIGFe4no1wFKq3hikBe?= =?us-ascii?Q?90I1OxMOeztcknz8DmbXqdj9p9chgp17w+8g6DS+lGJqmHG0FDVAClzznO0C?= =?us-ascii?Q?HJJI++whnwvExoSKp1y1FHQp8BQjaj/i5+DjTbYT+DMqZi7T5qbgWJT52YxD?= =?us-ascii?Q?WC530SRoJYKMgl90LZX8pnZMEjFsXBak9o5oAybJJLUzbM9pdZSj/8tGMC/W?= =?us-ascii?Q?gNAQjkAQw/I/kiSsuEYwKBlMqLgVS9qqoElVWC3T1uqV7lIOBQ5W4XQ6YaIJ?= =?us-ascii?Q?V7vQhub6DNIJdSdKhNIER/8zs42TKyCYZMmMbTZ670phjw7NegIEoAtcKsvw?= =?us-ascii?Q?MQEC1RTmd3r9kkREjCwl2TI9V2XVGtBgVy1SZcaSJC+zEnhJhmAMq92basE3?= =?us-ascii?Q?CjQc0waFUM6nJawHSsmS6KbZ47JqE4lYKv5Dqa55ZwsvUBm/UfoJEaVb0aRc?= =?us-ascii?Q?Fwae1wcQR9dpWzYXOoOVX38nES/3?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: intopix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PR3P192MB0748.EURP192.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 46c6baf8-67a1-479c-1610-08d91157f6f9 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2021 12:59:35.1886 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5f9168c7-cdac-4b23-9509-c278399e3c1f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: C/qtPzhVIYgpTIBMO/KfysJO8iIvTr58e1k3wCrHPum49xYaXVsaYtqsz2l7jBoJ X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXP192MB1167 X-MDID: 1620392377-N6mwSqKK9T1Q Archived-At: Subject: Re: [AVTCORE] Genart last call review of draft-ietf-payload-rtp-jpegxs-12 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2021 12:59:48 -0000 Dear Russ, Thank you for the review and the comments. Please find the following answer= s to your comments below. I have modified the draft and uploaded a -13 vers= ion. > Major Concerns: > Section 7.2.1: Does the SHALL related to [SMPTE-ST2110-10] only apply wh= en TP=3D2110TPNL or TP=3D2110TPW? Please reword to be clear when this SHAL= L statement applies. The short answer is yes, the SHALL only applies when using the RTP specific= ation in combination with SMPTE ST 2110. But, we chose to remove the SHALL = sentence about ST 2110. Originally it was trying to say that in the case of= using this RTP Payload under a SMPTE ST 2110 system, that the SDP descript= ion must then also follow the rules of STMPTE ST 2110-10. But, it is eviden= t that when implementing another standard, the one must follow that standar= d. It is a concern of a ST 2110 implementer. For this specification it chan= ges nothing specifically (ST 2110-10 mandates some specific SDP fields and = values, but this is allowed by the memo). We specifically made these change= s to allow the RTP payload to be used also outside of a ST 2110 ecosystem. > Minor Concerns: > Section 3.3: I do not have [ISO21122-2], and obviously an implementer wi= ll need that document. Can a bit more be said about "the profile" and "the= level and sublevel used" without making this document too big? I am able = to get a feel for the other things listed here from their names. We reworked this section to clarify better the concepts of the profile and = level/sublevel fields, without duplicating content from ISO21122-2. > Section 3.4: Can you please provide some explanation of the "frat field"= ? We reformulated the text a bit and added an explicit reference for the frat= field to ISO21122-3 where it is defined. > Nits: > Section 3.2: I do not understand the the last sentence? Is it the same = as: It represents sample values of a single image, without any interpretati= on relative to a colour space. Yes, that is correct. We changed the sentence to use your suggested wording= . > Section 5: s/of ST 2110-21 do not /of [SMPTE-ST2110-21] do not / We have updated the reference. I hope this addresses all concerns. If not, please let us know. Best regards, Tim Bruylants. -----Original Message----- From: avt On Behalf Of Russ Housley via Datatracker Sent: Thursday 6 May 2021 19:49 To: gen-art@ietf.org Cc: last-call@ietf.org; avt@ietf.org; draft-ietf-payload-rtp-jpegxs.all@iet= f.org Subject: [AVTCORE] Genart last call review of draft-ietf-payload-rtp-jpegxs= -12 Reviewer: Russ Housley Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review = Team (Gen-ART) reviews all IETF documents being processed by the IESG for t= he IETF Chair. Please treat these comments just like any other last call c= omments. For more information, please see the FAQ at . Document: draft-ietf-payload-rtp-jpegxs-12 Reviewer: Russ Housley Review Date: 2021-05-06 IETF LC End Date: 2021-05-17 IESG Telechat date: Unknown Summary: Almost Ready Major Concerns: Section 7.2.1: Does the SHALL related to [SMPTE-ST2110-10] only apply when= TP=3D2110TPNL or TP=3D2110TPW? Please reword to be clear when this SHALL = statement applies. Minor Concerns: Section 3.3: I do not have [ISO21122-2], and obviously an implementer will= need that document. Can a bit more be said about "the profile" and "the level and sublevel used" without making this document too big? I = am able to get a feel for the other things listed here from their names. Section 3.4: Can you please provide some explanation of the "frat field"? Nits: Section 3.2: I do not understand the the last sentence? Is it the same as= : It represents sample values of a single image, without any interpretation= relative to a colour space. Section 5: s/of ST 2110-21 do not /of [SMPTE-ST2110-21] do not / _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_avt&d=3DDwICAg&c=3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r= =3DLTxUGukLCEfEUdo_bq048Q&m=3Dz2S49lWIieCrrBDNEiE0OzMQ61wadfshm9Ih9Hhkn2s&s= =3Do16hyf29LBiyL98baNxoA8_0Xsng0H8HPcS4gX7o9qA&e=3D From nobody Fri May 7 07:58:46 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C1F3A2515 for ; Fri, 7 May 2021 07:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUAlZHVNEdA6 for ; Fri, 7 May 2021 07:58:37 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BED73A2517 for ; Fri, 7 May 2021 07:58:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 69A12300B10 for ; Fri, 7 May 2021 10:58:35 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id aDPdSD7Tl2Pa for ; Fri, 7 May 2021 10:58:29 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 4ADEC300B38; Fri, 7 May 2021 10:58:29 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.20\)) From: Russ Housley In-Reply-To: Date: Fri, 7 May 2021 10:58:29 -0400 Cc: IETF Gen-ART , "last-call@ietf.org" , "avt@ietf.org" , "draft-ietf-payload-rtp-jpegxs.all@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8C0EBAF1-5562-4959-AEEC-894187CA6B49@vigilsec.com> References: <162032334274.10241.3586337784439040714@ietfa.amsl.com> To: Tim Bruylants X-Mailer: Apple Mail (2.3445.104.20) Archived-At: Subject: Re: [AVTCORE] Genart last call review of draft-ietf-payload-rtp-jpegxs-12 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2021 14:58:42 -0000 Tim: > Thank you for the review and the comments. Please find the following = answers to your comments below. I have modified the draft and uploaded a = -13 version. >=20 >=20 >> Major Concerns: >> Section 7.2.1: Does the SHALL related to [SMPTE-ST2110-10] only = apply when TP=3D2110TPNL or TP=3D2110TPW? Please reword to be clear = when this SHALL statement applies. >=20 > The short answer is yes, the SHALL only applies when using the RTP = specification in combination with SMPTE ST 2110. But, we chose to remove = the SHALL sentence about ST 2110. Originally it was trying to say that = in the case of using this RTP Payload under a SMPTE ST 2110 system, that = the SDP description must then also follow the rules of STMPTE ST = 2110-10. But, it is evident that when implementing another standard, the = one must follow that standard. It is a concern of a ST 2110 implementer. = For this specification it changes nothing specifically (ST 2110-10 = mandates some specific SDP fields and values, but this is allowed by the = memo). We specifically made these changes to allow the RTP payload to be = used also outside of a ST 2110 ecosystem. That resolves my concern; thanks. >> Minor Concerns: >> Section 3.3: I do not have [ISO21122-2], and obviously an = implementer will need that document. Can a bit more be said about "the = profile" and "the level and sublevel used" without making this document = too big? I am able to get a feel for the other things listed here from = their names. >=20 > We reworked this section to clarify better the concepts of the profile = and level/sublevel fields, without duplicating content from ISO21122-2. This helps; thanks. >> Section 3.4: Can you please provide some explanation of the "frat = field"? >=20 > We reformulated the text a bit and added an explicit reference for the = frat field to ISO21122-3 where it is defined. Thanks for adding that context. >> Nits: >> Section 3.2: I do not understand the the last sentence? Is it the = same as: It represents sample values of a single image, without any = interpretation relative to a colour space. >=20 > Yes, that is correct. We changed the sentence to use your suggested = wording. That is more clear to me; thanks. >> Section 5: s/of ST 2110-21 do not /of [SMPTE-ST2110-21] do not / >=20 > We have updated the reference. Thanks. Russ From nobody Fri May 7 08:45:45 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39FE3A2703; Fri, 7 May 2021 08:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jpl004rh7ntQ; Fri, 7 May 2021 08:45:38 -0700 (PDT) Received: from smtp.egensajt.se (smtp.egensajt.se [193.42.159.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 615C23A26FF; Fri, 7 May 2021 08:45:37 -0700 (PDT) Received: from [192.168.2.137] (h77-53-37-81.cust.a3fiber.se [77.53.37.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 2F951202E6; Fri, 7 May 2021 17:45:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1620402329; bh=aBAHJDy+SfWScR2XtSA1GJ6pB+95raK69GMCkTtfhsw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=NKM/TJTI+6DaWJQ5aa01JNOgl2OaHWNLzJGQ5ATHxwaTVYADubGr75moPTCrWd1yG bZ9L0LzvaCrqbFXOe59eSvMQGNQtNT4Qreazb8bWdoaiAOjvJ+XN8x03PXgsZBGzr2 SvSMIIJ6JzgcZ12sGojRuWJvZl5DJx8HHkckr2q0= To: Rich Salz , secdir@ietf.org Cc: last-call@ietf.org, draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org, avt@ietf.org References: <162031178943.8783.4063437681950995450@ietfa.amsl.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <683ac9fe-b68f-3041-fff4-c26fef3767a8@ghaccess.se> Date: Fri, 7 May 2021 17:45:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <162031178943.8783.4063437681950995450@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------CE9D9C7C43DF755520DB6DEC" Content-Language: sv Archived-At: Subject: Re: [AVTCORE] Secdir last call review of draft-ietf-avtcore-multi-party-rtt-mix-16 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2021 15:45:44 -0000 This is a multi-part message in MIME format. --------------CE9D9C7C43DF755520DB6DEC Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Rich, Thanks for the review. I am composing a new version because of the Gen-ART review, and want to propose changes to satisfy your comments. You ask if it is common to have the mixers being trusted. In the expected first implementation environments for this draft, it is. That is in emergency service networks. Also in personal communication services it is. The first implementation environments are also expected to use the SIP centralized conference model (RFC 4353 etc.) where all media are expected to be mixed centrally. Thus the security aspects would be similar for audio, video and real-time text. I have tried to elaborate a bit more on this in a modified security considerations section, currently looking like this and being ready for submission together with the changes because of the Gen-ART review. Would this satisfy your concerns? --------Proposed security concerns-------------------- 11. Security Considerations The RTP-mixer model requires the mixer to be allowed to decrypt, pack, and encrypt secured text from the conference participants. Therefore the mixer needs to be trusted to achieve security in confidentiality and integrity. This situation is similar to the situation for handling audio and video media in centralized mixers. The requirement to transfer information about the user in RTCP reports in SDES, CNAME, and NAME fields, and in conference notifications, for creation of labels may have privacy concerns as already stated in RFC 3550 [RFC3550], and may be restricted for privacy reasons. The receiving user will then get a more symbolic label for the source. Participants with malicious intentions may appear and e.g., disturb the multiparty session by emitting a continuous flow of text. They may also send text that appears to originate from other participants. Counteractions should be to require secure signaling, media and authentication, and to provide higher level conference functions e.g., for blocking, muting, and expelling participants. Further security considerations specific for this application are specified in Section 3.19. ---------------------------------------------------------- Regards Gunnar -- Gunnar Hellstrm GHAccess gunnar.hellstrom@ghaccess.se Den 2021-05-06 kl. 16:36, skrev Rich Salz via Datatracker: > Reviewer: Rich Salz > Review result: Ready > > This review is for the benefit of the Security AD's. Nobody else should read > this. Or, if you read it, treat it as any other last call review :) > > I know very little about WebRTC, AVT, etc. > > I thought Section 1.2, summary of the alternatives, was great. I wish more > documents did this kind of thing. And similar for all of section 2. The details > in Section 3 about how to comply seem very clear. If I were implementing this, > I could use easily use this as a checklist and test suite. Section 3.19 is the > most important one for transport security. Not knowing the operating > environments, it seems reasonable. > > The security considerations seems a little scant, given the opportunity for > privacy concerns of participants and for intruders to disrupt calls. Is it > common that the mixer is a trusted entity? A statement on that either way would > be useful. > > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt -- Gunnar Hellstrm GHAccess gunnar.hellstrom@ghaccess.se --------------CE9D9C7C43DF755520DB6DEC Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Rich,

Thanks for the review.

I am composing a new version because of the Gen-ART review, and want to propose changes to satisfy your comments.

You ask if it is common to have the mixers being trusted.

In the expected first implementation environments for this draft, it is. That is in emergency service networks. Also in personal communication services it is.

The first implementation environments are also expected to use the SIP centralized conference model (RFC 4353 etc.) where all media are expected to be mixed centrally. Thus the security aspects would be similar for audio, video and real-time text.

I have tried to elaborate a bit more on this in a modified security considerations section, currently looking like this and being ready for submission together with the changes because of the Gen-ART review. Would this satisfy your concerns?

--------Proposed security concerns--------------------

11.  Security Considerations

   The RTP-mixer model requires the mixer to be allowed to decrypt,
   pack, and encrypt secured text from the conference participants.
   Therefore the mixer needs to be trusted to achieve security in
   confidentiality and integrity.  This situation is similar to the
   situation for handling audio and video media in centralized mixers.

   The requirement to transfer information about the user in RTCP
   reports in SDES, CNAME, and NAME fields, and in conference
   notifications, for creation of labels may have privacy concerns as
   already stated in RFC 3550 [RFC3550], and may be restricted for
   privacy reasons.  The receiving user will then get a more symbolic
   label for the source.

   Participants with malicious intentions may appear and e.g., disturb
   the multiparty session by emitting a continuous flow of text.  They
   may also send text that appears to originate from other participants.
   Counteractions should be to require secure signaling, media and
   authentication, and to provide higher level conference functions
   e.g., for blocking, muting, and expelling participants.

   Further security considerations specific for this application are
   specified in Section 3.19.
----------------------------------------------------------

Regards

Gunnar

-- 
Gunnar Hellstrm
GHAccess
gunnar.hellstrom@ghaccess.se
Den 2021-05-06 kl. 16:36, skrev Rich Salz via Datatracker:
Reviewer: Rich Salz
Review result: Ready

This review is for the benefit of the Security AD's. Nobody else should read
this. Or, if you read it, treat it as any other last call review :)

I know very little about WebRTC, AVT, etc.

I thought Section 1.2, summary of the alternatives, was great. I wish more
documents did this kind of thing. And similar for all of section 2. The details
in Section 3 about how to comply seem very clear. If I were implementing this,
I could use easily use this as a checklist and test suite. Section 3.19 is the
most important one for transport security. Not knowing the operating
environments, it seems reasonable.

The security considerations seems a little scant, given the opportunity for
privacy concerns of participants and for intruders to disrupt calls. Is it
common that the mixer is a trusted entity? A statement on that either way would
be useful.



_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt

-- 
Gunnar Hellstrm
GHAccess
gunnar.hellstrom@ghaccess.se
--------------CE9D9C7C43DF755520DB6DEC-- From nobody Fri May 7 09:13:41 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854B43A247C; Fri, 7 May 2021 09:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meQ8KrkRYTEp; Fri, 7 May 2021 09:13:30 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F096E3A2011; Fri, 7 May 2021 09:13:29 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 147GAuH2024379; Fri, 7 May 2021 17:13:18 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=w41SML2WKPuzLx0i4h8GB9h5GgKDHeqButvIQIh0oLE=; b=LhZ1RC1qJhrZW2+3/BrjvumTFVPkOER2XILjptDba66ZKFAhv/vBq0SukZRdqCfqnUd3 dOOj8+g+2T0RlPRjUOCOlIIMzZcrpx9dM2MwvYc6TbS9E1aAR/TSlK//nhSpkVk1f37M An76xuzELvMjqPEMhDlggRXokpqnulU/X/AEFwscnzV+/m1wTZDDVGfxdHGvBBxDJ8RI RlTXkPvKYf9wqDiEQSxrBQCQOfwJ5WduipnocSUde0PAvsOZFr9a/gGJOObC2NJf4M+T CZOrV4RwLXSwsnuU/MwgSQcqE9UAWkXyrU8iEy2tfEl5fyHqpT80FZU26B/oPNGji/Wc fA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 38csrf6tvb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 May 2021 17:13:18 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 147G58U9014099; Fri, 7 May 2021 12:13:16 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 38ct85334m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 07 May 2021 12:13:16 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 7 May 2021 12:13:16 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.012; Fri, 7 May 2021 12:13:15 -0400 From: "Salz, Rich" To: =?utf-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= , "secdir@ietf.org" CC: "last-call@ietf.org" , "draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org" , "avt@ietf.org" Thread-Topic: [AVTCORE] Secdir last call review of draft-ietf-avtcore-multi-party-rtt-mix-16 Thread-Index: AQHXQ1gFdwCZnyD0G0WItRsxVbOVjKrYMRSA Date: Fri, 7 May 2021 16:13:15 +0000 Message-ID: References: <162031178943.8783.4063437681950995450@ietfa.amsl.com> <683ac9fe-b68f-3041-fff4-c26fef3767a8@ghaccess.se> In-Reply-To: <683ac9fe-b68f-3041-fff4-c26fef3767a8@ghaccess.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.49.21050201 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_FF68D2FB7E524CBD9B632E787F1B8B47akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-07_06:2021-05-06, 2021-05-07 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 adultscore=0 phishscore=0 mlxlogscore=999 spamscore=0 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105070109 X-Proofpoint-ORIG-GUID: hZwiAkU_VmG7q8b9O0WyIT0TKnH7GiGI X-Proofpoint-GUID: hZwiAkU_VmG7q8b9O0WyIT0TKnH7GiGI X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-07_06:2021-05-06, 2021-05-07 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 impostorscore=0 lowpriorityscore=0 clxscore=1011 adultscore=0 suspectscore=0 phishscore=0 mlxscore=0 mlxlogscore=999 priorityscore=1501 spamscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105070109 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.18) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint1 Archived-At: Subject: Re: [AVTCORE] Secdir last call review of draft-ietf-avtcore-multi-party-rtt-mix-16 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2021 16:13:36 -0000 --_000_FF68D2FB7E524CBD9B632E787F1B8B47akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgZXhwbGFuYXRpb24gYW5kIHVwZGF0ZS4gIFlvdXIgdXBkYXRlZCBkcmFm dCBhZGRyZXNzZXMgbXkgY29uY2VybnMuICBQZXJoYXBzIDMuOSBzaG91bGQgaGF2ZSBhIGZvcndh cmQgbGluayB0byBTZWMgMTENCg0KRnJvbTogR3VubmFyIEhlbGxzdHLDtm0gPGd1bm5hci5oZWxs c3Ryb21AZ2hhY2Nlc3Muc2U+DQpEYXRlOiBGcmlkYXksIE1heSA3LCAyMDIxIGF0IDExOjQ1IEFN DQpUbzogUmljaCBTYWx6IDxyc2FsekBha2FtYWkuY29tPiwgInNlY2RpckBpZXRmLm9yZyIgPHNl Y2RpckBpZXRmLm9yZz4NCkNjOiAibGFzdC1jYWxsQGlldGYub3JnIiA8bGFzdC1jYWxsQGlldGYu b3JnPiwgImRyYWZ0LWlldGYtYXZ0Y29yZS1tdWx0aS1wYXJ0eS1ydHQtbWl4LmFsbEBpZXRmLm9y ZyIgPGRyYWZ0LWlldGYtYXZ0Y29yZS1tdWx0aS1wYXJ0eS1ydHQtbWl4LmFsbEBpZXRmLm9yZz4s ICJhdnRAaWV0Zi5vcmciIDxhdnRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0FWVENPUkVdIFNl Y2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtYXZ0Y29yZS1tdWx0aS1wYXJ0eS1y dHQtbWl4LTE2DQoNCg0KUmljaCwNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3Lg0KDQpJIGFtIGNv bXBvc2luZyBhIG5ldyB2ZXJzaW9uIGJlY2F1c2Ugb2YgdGhlIEdlbi1BUlQgcmV2aWV3LCBhbmQg d2FudCB0byBwcm9wb3NlIGNoYW5nZXMgdG8gc2F0aXNmeSB5b3VyIGNvbW1lbnRzLg0KDQpZb3Ug YXNrIGlmIGl0IGlzIGNvbW1vbiB0byBoYXZlIHRoZSBtaXhlcnMgYmVpbmcgdHJ1c3RlZC4NCg0K SW4gdGhlIGV4cGVjdGVkIGZpcnN0IGltcGxlbWVudGF0aW9uIGVudmlyb25tZW50cyBmb3IgdGhp cyBkcmFmdCwgaXQgaXMuIFRoYXQgaXMgaW4gZW1lcmdlbmN5IHNlcnZpY2UgbmV0d29ya3MuIEFs c28gaW4gcGVyc29uYWwgY29tbXVuaWNhdGlvbiBzZXJ2aWNlcyBpdCBpcy4NCg0KVGhlIGZpcnN0 IGltcGxlbWVudGF0aW9uIGVudmlyb25tZW50cyBhcmUgYWxzbyBleHBlY3RlZCB0byB1c2UgdGhl IFNJUCBjZW50cmFsaXplZCBjb25mZXJlbmNlIG1vZGVsIChSRkMgNDM1MyBldGMuKSB3aGVyZSBh bGwgbWVkaWEgYXJlIGV4cGVjdGVkIHRvIGJlIG1peGVkIGNlbnRyYWxseS4gVGh1cyB0aGUgc2Vj dXJpdHkgYXNwZWN0cyB3b3VsZCBiZSBzaW1pbGFyIGZvciBhdWRpbywgdmlkZW8gYW5kIHJlYWwt dGltZSB0ZXh0Lg0KDQpJIGhhdmUgdHJpZWQgdG8gZWxhYm9yYXRlIGEgYml0IG1vcmUgb24gdGhp cyBpbiBhIG1vZGlmaWVkIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24sIGN1cnJlbnRs eSBsb29raW5nIGxpa2UgdGhpcyBhbmQgYmVpbmcgcmVhZHkgZm9yIHN1Ym1pc3Npb24gdG9nZXRo ZXIgd2l0aCB0aGUgY2hhbmdlcyBiZWNhdXNlIG9mIHRoZSBHZW4tQVJUIHJldmlldy4gV291bGQg dGhpcyBzYXRpc2Z5IHlvdXIgY29uY2VybnM/DQoNCi0tLS0tLS0tUHJvcG9zZWQgc2VjdXJpdHkg Y29uY2VybnMtLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoxMS4gIFNlY3VyaXR5IENvbnNpZGVyYXRp b25zDQoNCg0KDQogICBUaGUgUlRQLW1peGVyIG1vZGVsIHJlcXVpcmVzIHRoZSBtaXhlciB0byBi ZSBhbGxvd2VkIHRvIGRlY3J5cHQsDQoNCiAgIHBhY2ssIGFuZCBlbmNyeXB0IHNlY3VyZWQgdGV4 dCBmcm9tIHRoZSBjb25mZXJlbmNlIHBhcnRpY2lwYW50cy4NCg0KICAgVGhlcmVmb3JlIHRoZSBt aXhlciBuZWVkcyB0byBiZSB0cnVzdGVkIHRvIGFjaGlldmUgc2VjdXJpdHkgaW4NCg0KICAgY29u ZmlkZW50aWFsaXR5IGFuZCBpbnRlZ3JpdHkuICBUaGlzIHNpdHVhdGlvbiBpcyBzaW1pbGFyIHRv IHRoZQ0KDQogICBzaXR1YXRpb24gZm9yIGhhbmRsaW5nIGF1ZGlvIGFuZCB2aWRlbyBtZWRpYSBp biBjZW50cmFsaXplZCBtaXhlcnMuDQoNCg0KDQogICBUaGUgcmVxdWlyZW1lbnQgdG8gdHJhbnNm ZXIgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHVzZXIgaW4gUlRDUA0KDQogICByZXBvcnRzIGluIFNE RVMsIENOQU1FLCBhbmQgTkFNRSBmaWVsZHMsIGFuZCBpbiBjb25mZXJlbmNlDQoNCiAgIG5vdGlm aWNhdGlvbnMsIGZvciBjcmVhdGlvbiBvZiBsYWJlbHMgbWF5IGhhdmUgcHJpdmFjeSBjb25jZXJu cyBhcw0KDQogICBhbHJlYWR5IHN0YXRlZCBpbiBSRkMgMzU1MCBbUkZDMzU1MF0sIGFuZCBtYXkg YmUgcmVzdHJpY3RlZCBmb3INCg0KICAgcHJpdmFjeSByZWFzb25zLiAgVGhlIHJlY2VpdmluZyB1 c2VyIHdpbGwgdGhlbiBnZXQgYSBtb3JlIHN5bWJvbGljDQoNCiAgIGxhYmVsIGZvciB0aGUgc291 cmNlLg0KDQoNCg0KICAgUGFydGljaXBhbnRzIHdpdGggbWFsaWNpb3VzIGludGVudGlvbnMgbWF5 IGFwcGVhciBhbmQgZS5nLiwgZGlzdHVyYg0KDQogICB0aGUgbXVsdGlwYXJ0eSBzZXNzaW9uIGJ5 IGVtaXR0aW5nIGEgY29udGludW91cyBmbG93IG9mIHRleHQuICBUaGV5DQoNCiAgIG1heSBhbHNv IHNlbmQgdGV4dCB0aGF0IGFwcGVhcnMgdG8gb3JpZ2luYXRlIGZyb20gb3RoZXIgcGFydGljaXBh bnRzLg0KDQogICBDb3VudGVyYWN0aW9ucyBzaG91bGQgYmUgdG8gcmVxdWlyZSBzZWN1cmUgc2ln bmFsaW5nLCBtZWRpYSBhbmQNCg0KICAgYXV0aGVudGljYXRpb24sIGFuZCB0byBwcm92aWRlIGhp Z2hlciBsZXZlbCBjb25mZXJlbmNlIGZ1bmN0aW9ucw0KDQogICBlLmcuLCBmb3IgYmxvY2tpbmcs IG11dGluZywgYW5kIGV4cGVsbGluZyBwYXJ0aWNpcGFudHMuDQoNCg0KDQogICBGdXJ0aGVyIHNl Y3VyaXR5IGNvbnNpZGVyYXRpb25zIHNwZWNpZmljIGZvciB0aGlzIGFwcGxpY2F0aW9uIGFyZQ0K DQogICBzcGVjaWZpZWQgaW4gU2VjdGlvbiAzLjE5Lg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQpSZWdhcmRzDQoNCg0K DQpHdW5uYXINCg0KLS0NCg0KR3VubmFyIEhlbGxzdHLDtm0NCg0KR0hBY2Nlc3MNCg0KZ3VubmFy LmhlbGxzdHJvbUBnaGFjY2Vzcy5zZTxtYWlsdG86Z3VubmFyLmhlbGxzdHJvbUBnaGFjY2Vzcy5z ZT4NCkRlbiAyMDIxLTA1LTA2IGtsLiAxNjozNiwgc2tyZXYgUmljaCBTYWx6IHZpYSBEYXRhdHJh Y2tlcjoNCg0KUmV2aWV3ZXI6IFJpY2ggU2Fseg0KDQpSZXZpZXcgcmVzdWx0OiBSZWFkeQ0KDQoN Cg0KVGhpcyByZXZpZXcgaXMgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBTZWN1cml0eSBBRCdzLiBO b2JvZHkgZWxzZSBzaG91bGQgcmVhZA0KDQp0aGlzLiBPciwgaWYgeW91IHJlYWQgaXQsIHRyZWF0 IGl0IGFzIGFueSBvdGhlciBsYXN0IGNhbGwgcmV2aWV3IDopDQoNCg0KDQpJIGtub3cgdmVyeSBs aXR0bGUgYWJvdXQgV2ViUlRDLCBBVlQsIGV0Yy4NCg0KDQoNCkkgdGhvdWdodCBTZWN0aW9uIDEu Miwgc3VtbWFyeSBvZiB0aGUgYWx0ZXJuYXRpdmVzLCB3YXMgZ3JlYXQuIEkgd2lzaCBtb3JlDQoN CmRvY3VtZW50cyBkaWQgdGhpcyBraW5kIG9mIHRoaW5nLiBBbmQgc2ltaWxhciBmb3IgYWxsIG9m IHNlY3Rpb24gMi4gVGhlIGRldGFpbHMNCg0KaW4gU2VjdGlvbiAzIGFib3V0IGhvdyB0byBjb21w bHkgc2VlbSB2ZXJ5IGNsZWFyLiBJZiBJIHdlcmUgaW1wbGVtZW50aW5nIHRoaXMsDQoNCkkgY291 bGQgdXNlIGVhc2lseSB1c2UgdGhpcyBhcyBhIGNoZWNrbGlzdCBhbmQgdGVzdCBzdWl0ZS4gU2Vj dGlvbiAzLjE5IGlzIHRoZQ0KDQptb3N0IGltcG9ydGFudCBvbmUgZm9yIHRyYW5zcG9ydCBzZWN1 cml0eS4gTm90IGtub3dpbmcgdGhlIG9wZXJhdGluZw0KDQplbnZpcm9ubWVudHMsIGl0IHNlZW1z IHJlYXNvbmFibGUuDQoNCg0KDQpUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VlbXMgYSBs aXR0bGUgc2NhbnQsIGdpdmVuIHRoZSBvcHBvcnR1bml0eSBmb3INCg0KcHJpdmFjeSBjb25jZXJu cyBvZiBwYXJ0aWNpcGFudHMgYW5kIGZvciBpbnRydWRlcnMgdG8gZGlzcnVwdCBjYWxscy4gSXMg aXQNCg0KY29tbW9uIHRoYXQgdGhlIG1peGVyIGlzIGEgdHJ1c3RlZCBlbnRpdHk/IEEgc3RhdGVt ZW50IG9uIHRoYXQgZWl0aGVyIHdheSB3b3VsZA0KDQpiZSB1c2VmdWwuDQoNCg0KDQoNCg0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkF1ZGlv L1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQoNCmF2dEBpZXRmLm9yZzxtYWlsdG86 YXZ0QGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2 dDxodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2F2dF9fOyEhR2p2VHpfdmshQ2hOUF80QzhfLUlHOWxFcS1MRGw5MzB3OWk5YjhH WUlscGNGb0JwMW5VSzdMR3hPNzhRMGhYeXFyN1FUJD4NCg0KLS0NCg0KR3VubmFyIEhlbGxzdHLD tm0NCg0KR0hBY2Nlc3MNCg0KZ3VubmFyLmhlbGxzdHJvbUBnaGFjY2Vzcy5zZTxtYWlsdG86Z3Vu bmFyLmhlbGxzdHJvbUBnaGFjY2Vzcy5zZT4NCg== --_000_FF68D2FB7E524CBD9B632E787F1B8B47akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <9F27AD31ABB79646BFA5A7DB4EB6C620@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbWFyZ2luOjBpbjsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFzIixz ZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3Jk Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFu a3MgZm9yIHRoZSBleHBsYW5hdGlvbiBhbmQgdXBkYXRlLiZuYnNwOyBZb3VyIHVwZGF0ZWQgZHJh ZnQgYWRkcmVzc2VzIG15IGNvbmNlcm5zLiZuYnNwOyBQZXJoYXBzIDMuOSBzaG91bGQgaGF2ZSBh IGZvcndhcmQgbGluayB0byBTZWMgMTE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPkd1bm5hciBIZWxsc3Ryw7ZtICZsdDtndW5uYXIuaGVsbHN0cm9tQGdoYWNjZXNz LnNlJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIE1heSA3LCAyMDIxIGF0IDExOjQ1IEFN PGJyPg0KPGI+VG86IDwvYj5SaWNoIFNhbHogJmx0O3JzYWx6QGFrYW1haS5jb20mZ3Q7LCAmcXVv dDtzZWNkaXJAaWV0Zi5vcmcmcXVvdDsgJmx0O3NlY2RpckBpZXRmLm9yZyZndDs8YnI+DQo8Yj5D YzogPC9iPiZxdW90O2xhc3QtY2FsbEBpZXRmLm9yZyZxdW90OyAmbHQ7bGFzdC1jYWxsQGlldGYu b3JnJmd0OywgJnF1b3Q7ZHJhZnQtaWV0Zi1hdnRjb3JlLW11bHRpLXBhcnR5LXJ0dC1taXguYWxs QGlldGYub3JnJnF1b3Q7ICZsdDtkcmFmdC1pZXRmLWF2dGNvcmUtbXVsdGktcGFydHktcnR0LW1p eC5hbGxAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDthdnRAaWV0Zi5vcmcmcXVvdDsgJmx0O2F2dEBpZXRm Lm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtBVlRDT1JFXSBTZWNkaXIgbGFzdCBj YWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWF2dGNvcmUtbXVsdGktcGFydHktcnR0LW1peC0xNjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cD5SaWNoLDxvOnA+PC9vOnA+PC9wPg0K PHA+VGhhbmtzIGZvciB0aGUgcmV2aWV3LjxvOnA+PC9vOnA+PC9wPg0KPHA+SSBhbSBjb21wb3Np bmcgYSBuZXcgdmVyc2lvbiBiZWNhdXNlIG9mIHRoZSBHZW4tQVJUIHJldmlldywgYW5kIHdhbnQg dG8gcHJvcG9zZSBjaGFuZ2VzIHRvIHNhdGlzZnkgeW91ciBjb21tZW50cy4NCjxvOnA+PC9vOnA+ PC9wPg0KPHA+WW91IGFzayBpZiBpdCBpcyBjb21tb24gdG8gaGF2ZSB0aGUgbWl4ZXJzIGJlaW5n IHRydXN0ZWQuIDxvOnA+PC9vOnA+PC9wPg0KPHA+SW4gdGhlIGV4cGVjdGVkIGZpcnN0IGltcGxl bWVudGF0aW9uIGVudmlyb25tZW50cyBmb3IgdGhpcyBkcmFmdCwgaXQgaXMuIFRoYXQgaXMgaW4g ZW1lcmdlbmN5IHNlcnZpY2UgbmV0d29ya3MuIEFsc28gaW4gcGVyc29uYWwgY29tbXVuaWNhdGlv biBzZXJ2aWNlcyBpdCBpcy48bzpwPjwvbzpwPjwvcD4NCjxwPlRoZSBmaXJzdCBpbXBsZW1lbnRh dGlvbiBlbnZpcm9ubWVudHMgYXJlIGFsc28gZXhwZWN0ZWQgdG8gdXNlIHRoZSBTSVAgY2VudHJh bGl6ZWQgY29uZmVyZW5jZSBtb2RlbCAoUkZDIDQzNTMgZXRjLikgd2hlcmUgYWxsIG1lZGlhIGFy ZSBleHBlY3RlZCB0byBiZSBtaXhlZCBjZW50cmFsbHkuIFRodXMgdGhlIHNlY3VyaXR5IGFzcGVj dHMgd291bGQgYmUgc2ltaWxhciBmb3IgYXVkaW8sIHZpZGVvIGFuZCByZWFsLXRpbWUgdGV4dC4N CjxvOnA+PC9vOnA+PC9wPg0KPHA+SSBoYXZlIHRyaWVkIHRvIGVsYWJvcmF0ZSBhIGJpdCBtb3Jl IG9uIHRoaXMgaW4gYSBtb2RpZmllZCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLCBj dXJyZW50bHkgbG9va2luZyBsaWtlIHRoaXMgYW5kIGJlaW5nIHJlYWR5IGZvciBzdWJtaXNzaW9u IHRvZ2V0aGVyIHdpdGggdGhlIGNoYW5nZXMgYmVjYXVzZSBvZiB0aGUgR2VuLUFSVCByZXZpZXcu IFdvdWxkIHRoaXMgc2F0aXNmeSB5b3VyIGNvbmNlcm5zPzxvOnA+PC9vOnA+PC9wPg0KPHA+LS0t LS0tLS1Qcm9wb3NlZCBzZWN1cml0eSBjb25jZXJucy0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48 L286cD48L3A+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7Zm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiAyO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dz OiAyOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt0ZXh0LWRlY29yYXRpb24tdGhpY2tu ZXNzOiBpbml0aWFsO3RleHQtZGVjb3JhdGlvbi1zdHlsZTogaW5pdGlhbDt0ZXh0LWRlY29yYXRp b24tY29sb3I6IGluaXRpYWw7b3ZlcmZsb3ctd3JhcDogYnJlYWstd29yZDt3aGl0ZS1zcGFjZTpw cmUtd3JhcDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjExLiZu YnNwOyBTZWN1cml0eSBDb25zaWRlcmF0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBUaGUgUlRQLW1p eGVyIG1vZGVsIHJlcXVpcmVzIHRoZSBtaXhlciB0byBiZSBhbGxvd2VkIHRvIGRlY3J5cHQsPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7IHBhY2ssIGFuZCBlbmNyeXB0IHNlY3VyZWQgdGV4dCBmcm9tIHRoZSBjb25mZXJl bmNlIHBhcnRpY2lwYW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgVGhlcmVmb3JlIHRoZSBtaXhlciBuZWVkcyB0 byBiZSB0cnVzdGVkIHRvIGFjaGlldmUgc2VjdXJpdHkgaW48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgY29uZmlkZW50 aWFsaXR5IGFuZCBpbnRlZ3JpdHkuJm5ic3A7IFRoaXMgc2l0dWF0aW9uIGlzIHNpbWlsYXIgdG8g dGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7IHNpdHVhdGlvbiBmb3IgaGFuZGxpbmcgYXVkaW8gYW5kIHZpZGVvIG1l ZGlhIGluIGNlbnRyYWxpemVkIG1peGVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgVGhlIHJlcXVpcmVt ZW50IHRvIHRyYW5zZmVyIGluZm9ybWF0aW9uIGFib3V0IHRoZSB1c2VyIGluIFJUQ1A8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgcmVwb3J0cyBpbiBTREVTLCBDTkFNRSwgYW5kIE5BTUUgZmllbGRzLCBhbmQgaW4gY29u ZmVyZW5jZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyBub3RpZmljYXRpb25zLCBmb3IgY3JlYXRpb24gb2YgbGFiZWxz IG1heSBoYXZlIHByaXZhY3kgY29uY2VybnMgYXM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYWxyZWFkeSBzdGF0ZWQg aW4gUkZDIDM1NTAgW1JGQzM1NTBdLCBhbmQgbWF5IGJlIHJlc3RyaWN0ZWQgZm9yPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7IHByaXZhY3kgcmVhc29ucy4mbmJzcDsgVGhlIHJlY2VpdmluZyB1c2VyIHdpbGwgdGhlbiBn ZXQgYSBtb3JlIHN5bWJvbGljPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGxhYmVsIGZvciB0aGUgc291cmNlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyBQYXJ0aWNpcGFudHMgd2l0aCBtYWxpY2lvdXMgaW50ZW50aW9ucyBtYXkg YXBwZWFyIGFuZCBlLmcuLCBkaXN0dXJiPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHRoZSBtdWx0aXBhcnR5IHNlc3Np b24gYnkgZW1pdHRpbmcgYSBjb250aW51b3VzIGZsb3cgb2YgdGV4dC4mbmJzcDsgVGhleTxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyBtYXkgYWxzbyBzZW5kIHRleHQgdGhhdCBhcHBlYXJzIHRvIG9yaWdpbmF0ZSBmcm9t IG90aGVyIHBhcnRpY2lwYW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgQ291bnRlcmFjdGlvbnMgc2hvdWxkIGJl IHRvIHJlcXVpcmUgc2VjdXJlIHNpZ25hbGluZywgbWVkaWEgYW5kPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGF1dGhl bnRpY2F0aW9uLCBhbmQgdG8gcHJvdmlkZSBoaWdoZXIgbGV2ZWwgY29uZmVyZW5jZSBmdW5jdGlv bnM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsgZS5nLiwgZm9yIGJsb2NraW5nLCBtdXRpbmcsIGFuZCBleHBlbGxpbmcg cGFydGljaXBhbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBGdXJ0aGVyIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zIHNwZWNpZmljIGZvciB0aGlzIGFwcGxpY2F0aW9uIGFyZTxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBzcGVj aWZpZWQgaW4gU2VjdGlvbiAzLjE5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5SZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wcmU+DQo8cD5HdW5uYXI8bzpwPjwvbzpwPjwvcD4NCjxwcmU+LS0gPG86cD48L286cD48 L3ByZT4NCjxwcmU+R3VubmFyIEhlbGxzdHLDtm08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5HSEFj Y2VzczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpndW5uYXIuaGVsbHN0 cm9tQGdoYWNjZXNzLnNlIj5ndW5uYXIuaGVsbHN0cm9tQGdoYWNjZXNzLnNlPC9hPjxvOnA+PC9v OnA+PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVuIDIwMjEtMDUtMDYga2wu IDE2OjM2LCBza3JldiBSaWNoIFNhbHogdmlhIERhdGF0cmFja2VyOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwcmU+UmV2aWV3ZXI6IFJpY2ggU2FsejxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PlJldmlldyByZXN1bHQ6IFJlYWR5PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8 L286cD48L3ByZT4NCjxwcmU+VGhpcyByZXZpZXcgaXMgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBT ZWN1cml0eSBBRCdzLiBOb2JvZHkgZWxzZSBzaG91bGQgcmVhZDxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPnRoaXMuIE9yLCBpZiB5b3UgcmVhZCBpdCwgdHJlYXQgaXQgYXMgYW55IG90aGVyIGxhc3Qg Y2FsbCByZXZpZXcgOik8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPg0KPHByZT5JIGtub3cgdmVyeSBsaXR0bGUgYWJvdXQgV2ViUlRDLCBBVlQsIGV0Yy48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5JIHRob3Vn aHQgU2VjdGlvbiAxLjIsIHN1bW1hcnkgb2YgdGhlIGFsdGVybmF0aXZlcywgd2FzIGdyZWF0LiBJ IHdpc2ggbW9yZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmRvY3VtZW50cyBkaWQgdGhpcyBraW5k IG9mIHRoaW5nLiBBbmQgc2ltaWxhciBmb3IgYWxsIG9mIHNlY3Rpb24gMi4gVGhlIGRldGFpbHM8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5pbiBTZWN0aW9uIDMgYWJvdXQgaG93IHRvIGNvbXBseSBz ZWVtIHZlcnkgY2xlYXIuIElmIEkgd2VyZSBpbXBsZW1lbnRpbmcgdGhpcyw8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5JIGNvdWxkIHVzZSBlYXNpbHkgdXNlIHRoaXMgYXMgYSBjaGVja2xpc3QgYW5k IHRlc3Qgc3VpdGUuIFNlY3Rpb24gMy4xOSBpcyB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5t b3N0IGltcG9ydGFudCBvbmUgZm9yIHRyYW5zcG9ydCBzZWN1cml0eS4gTm90IGtub3dpbmcgdGhl IG9wZXJhdGluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmVudmlyb25tZW50cywgaXQgc2VlbXMg cmVhc29uYWJsZS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl Pg0KPHByZT5UaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VlbXMgYSBsaXR0bGUgc2NhbnQs IGdpdmVuIHRoZSBvcHBvcnR1bml0eSBmb3I8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5wcml2YWN5 IGNvbmNlcm5zIG9mIHBhcnRpY2lwYW50cyBhbmQgZm9yIGludHJ1ZGVycyB0byBkaXNydXB0IGNh bGxzLiBJcyBpdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmNvbW1vbiB0aGF0IHRoZSBtaXhlciBp cyBhIHRydXN0ZWQgZW50aXR5PyBBIHN0YXRlbWVudCBvbiB0aGF0IGVpdGhlciB3YXkgd291bGQ8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5iZSB1c2VmdWwuPG86cD48L286cD48L3ByZT4NCjxwcmU+ PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5BdWRpby9WaWRl byBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhy ZWY9Im1haWx0bzphdnRAaWV0Zi5vcmciPmF2dEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dF9fOyEhR2p2VHpfdmshQ2hOUF80QzhfLUlHOWxF cS1MRGw5MzB3OWk5YjhHWUlscGNGb0JwMW5VSzdMR3hPNzhRMGhYeXFyN1FUJCI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnQ8L2E+PG86cD48L286cD48L3ByZT4NCjwv YmxvY2txdW90ZT4NCjxwcmU+LS0gPG86cD48L286cD48L3ByZT4NCjxwcmU+R3VubmFyIEhlbGxz dHLDtm08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5HSEFjY2VzczxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxhIGhyZWY9Im1haWx0bzpndW5uYXIuaGVsbHN0cm9tQGdoYWNjZXNzLnNlIj5ndW5uYXIu aGVsbHN0cm9tQGdoYWNjZXNzLnNlPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_FF68D2FB7E524CBD9B632E787F1B8B47akamaicom_-- From nobody Fri May 7 10:47:28 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081813A2BB3; Fri, 7 May 2021 10:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wfS0YAQefZ6; Fri, 7 May 2021 10:47:21 -0700 (PDT) Received: from smtp.egensajt.se (smtp.egensajt.se [194.68.80.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0CF03A29EC; Fri, 7 May 2021 10:47:06 -0700 (PDT) Received: from [192.168.2.137] (h77-53-37-81.cust.a3fiber.se [77.53.37.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id D93E620FCE; Fri, 7 May 2021 19:47:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1620409624; bh=LrxfdhLdvbtUJPrmV3MRQsGshTyHa78jfRq+Fpkt+Qk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=EeF8HbVVbRJbsIDk2s692m1ogKaLQvNW5w0ME7GNkjqQIbK0lveHm297T7NvHNqdv iCWGIGem5/wG2UACuCRLni58xK91je4VVdftgFq7CgZUeCd0wYhs24g86v9+RhMWBV Mf2JFBpQIr7ARkdrr1LfXakfYx3W83AQ2/DFaCG4= To: "Salz, Rich" , "secdir@ietf.org" Cc: "last-call@ietf.org" , "draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org" , "avt@ietf.org" References: <162031178943.8783.4063437681950995450@ietfa.amsl.com> <683ac9fe-b68f-3041-fff4-c26fef3767a8@ghaccess.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Fri, 7 May 2021 19:47:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7BEBB1A4AD841BC0FF469135" Content-Language: sv Archived-At: Subject: Re: [AVTCORE] Secdir last call review of draft-ietf-avtcore-multi-party-rtt-mix-16 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2021 17:47:27 -0000 This is a multi-part message in MIME format. --------------7BEBB1A4AD841BC0FF469135 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks. I have added this sentence to section 3.19 " Further general security considerations are covered in    Section 11." Regards Gunnar Hellstrom -- Gunnar Hellström GHAccess gunnar.hellstrom@ghaccess.se Den 2021-05-07 kl. 18:13, skrev Salz, Rich: > > Thanks for the explanation and update. Your updated draft addresses my > concerns.  Perhaps 3.9 should have a forward link to Sec 11 > > *From: *Gunnar Hellström > *Date: *Friday, May 7, 2021 at 11:45 AM > *To: *Rich Salz , "secdir@ietf.org" > *Cc: *"last-call@ietf.org" , > "draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org" > , "avt@ietf.org" > > *Subject: *Re: [AVTCORE] Secdir last call review of > draft-ietf-avtcore-multi-party-rtt-mix-16 > > Rich, > > Thanks for the review. > > I am composing a new version because of the Gen-ART review, and want > to propose changes to satisfy your comments. > > You ask if it is common to have the mixers being trusted. > > In the expected first implementation environments for this draft, it > is. That is in emergency service networks. Also in personal > communication services it is. > > The first implementation environments are also expected to use the SIP > centralized conference model (RFC 4353 etc.) where all media are > expected to be mixed centrally. Thus the security aspects would be > similar for audio, video and real-time text. > > I have tried to elaborate a bit more on this in a modified security > considerations section, currently looking like this and being ready > for submission together with the changes because of the Gen-ART > review. Would this satisfy your concerns? > > --------Proposed security concerns-------------------- > > 11.  Security Considerations >    The RTP-mixer model requires the mixer to be allowed to decrypt, >    pack, and encrypt secured text from the conference participants. >    Therefore the mixer needs to be trusted to achieve security in >    confidentiality and integrity.  This situation is similar to the >    situation for handling audio and video media in centralized mixers. >    The requirement to transfer information about the user in RTCP >    reports in SDES, CNAME, and NAME fields, and in conference >    notifications, for creation of labels may have privacy concerns as >    already stated in RFC 3550 [RFC3550], and may be restricted for >    privacy reasons.  The receiving user will then get a more symbolic >    label for the source. >    Participants with malicious intentions may appear and e.g., disturb >    the multiparty session by emitting a continuous flow of text.  They >    may also send text that appears to originate from other participants. >    Counteractions should be to require secure signaling, media and >    authentication, and to provide higher level conference functions >    e.g., for blocking, muting, and expelling participants. >    Further security considerations specific for this application are >    specified in Section 3.19. > ---------------------------------------------------------- > Regards > > Gunnar > > -- > Gunnar Hellström > GHAccess > gunnar.hellstrom@ghaccess.se > > Den 2021-05-06 kl. 16:36, skrev Rich Salz via Datatracker: > > Reviewer: Rich Salz > > Review result: Ready > > This review is for the benefit of the Security AD's. Nobody else should read > > this. Or, if you read it, treat it as any other last call review :) > > I know very little about WebRTC, AVT, etc. > > I thought Section 1.2, summary of the alternatives, was great. I wish more > > documents did this kind of thing. And similar for all of section 2. The details > > in Section 3 about how to comply seem very clear. If I were implementing this, > > I could use easily use this as a checklist and test suite. Section 3.19 is the > > most important one for transport security. Not knowing the operating > > environments, it seems reasonable. > > The security considerations seems a little scant, given the opportunity for > > privacy concerns of participants and for intruders to disrupt calls. Is it > > common that the mixer is a trusted entity? A statement on that either way would > > be useful. > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > -- > Gunnar Hellström > GHAccess > gunnar.hellstrom@ghaccess.se -- Gunnar Hellström GHAccess gunnar.hellstrom@ghaccess.se --------------7BEBB1A4AD841BC0FF469135 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Thanks.

I have added this sentence to section 3.19

" Further general security considerations are covered in
   Section 11."

Regards

Gunnar Hellstrom

-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se


Den 2021-05-07 kl. 18:13, skrev Salz, Rich:

Thanks for the explanation and update.  Your updated draft addresses my concerns.  Perhaps 3.9 should have a forward link to Sec 11

 

From: Gunnar Hellström <gunnar.hellstrom@ghaccess.se>
Date: Friday, May 7, 2021 at 11:45 AM
To: Rich Salz <rsalz@akamai.com>, "secdir@ietf.org" <secdir@ietf.org>
Cc: "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org" <draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org>, "avt@ietf.org" <avt@ietf.org>
Subject: Re: [AVTCORE] Secdir last call review of draft-ietf-avtcore-multi-party-rtt-mix-16

 

Rich,

Thanks for the review.

I am composing a new version because of the Gen-ART review, and want to propose changes to satisfy your comments.

You ask if it is common to have the mixers being trusted.

In the expected first implementation environments for this draft, it is. That is in emergency service networks. Also in personal communication services it is.

The first implementation environments are also expected to use the SIP centralized conference model (RFC 4353 etc.) where all media are expected to be mixed centrally. Thus the security aspects would be similar for audio, video and real-time text.

I have tried to elaborate a bit more on this in a modified security considerations section, currently looking like this and being ready for submission together with the changes because of the Gen-ART review. Would this satisfy your concerns?

--------Proposed security concerns--------------------

11.  Security Considerations
 
   The RTP-mixer model requires the mixer to be allowed to decrypt,
   pack, and encrypt secured text from the conference participants.
   Therefore the mixer needs to be trusted to achieve security in
   confidentiality and integrity.  This situation is similar to the
   situation for handling audio and video media in centralized mixers.
 
   The requirement to transfer information about the user in RTCP
   reports in SDES, CNAME, and NAME fields, and in conference
   notifications, for creation of labels may have privacy concerns as
   already stated in RFC 3550 [RFC3550], and may be restricted for
   privacy reasons.  The receiving user will then get a more symbolic
   label for the source.
 
   Participants with malicious intentions may appear and e.g., disturb
   the multiparty session by emitting a continuous flow of text.  They
   may also send text that appears to originate from other participants.
   Counteractions should be to require secure signaling, media and
   authentication, and to provide higher level conference functions
   e.g., for blocking, muting, and expelling participants.
 
   Further security considerations specific for this application are
   specified in Section 3.19.
----------------------------------------------------------
 
Regards
 

Gunnar

-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se

Den 2021-05-06 kl. 16:36, skrev Rich Salz via Datatracker:

Reviewer: Rich Salz
Review result: Ready
 
This review is for the benefit of the Security AD's. Nobody else should read
this. Or, if you read it, treat it as any other last call review :)
 
I know very little about WebRTC, AVT, etc.
 
I thought Section 1.2, summary of the alternatives, was great. I wish more
documents did this kind of thing. And similar for all of section 2. The details
in Section 3 about how to comply seem very clear. If I were implementing this,
I could use easily use this as a checklist and test suite. Section 3.19 is the
most important one for transport security. Not knowing the operating
environments, it seems reasonable.
 
The security considerations seems a little scant, given the opportunity for
privacy concerns of participants and for intruders to disrupt calls. Is it
common that the mixer is a trusted entity? A statement on that either way would
be useful.
 
 
 
_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt
-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se
-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se
--------------7BEBB1A4AD841BC0FF469135-- From nobody Fri May 7 11:39:10 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED72C3A2715 for ; Fri, 7 May 2021 11:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=8x8.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKvYtasliHdo for ; Fri, 7 May 2021 11:38:44 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E14F3A2D6F for ; Fri, 7 May 2021 11:31:37 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id a2so9430921qkh.11 for ; Fri, 07 May 2021 11:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=8x8.com; s=googlemail; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=npiEoMw1NBAHEmWcSQJzt+lrN2y1/Mmq0X7Sbl5Nd3Q=; b=hR/3ie8ki9Gz8WLIPcjsBEen26dUSylpFA+IzWiZXiC8woLmh3vgr48BJsE1kNgfre Jyckwd4/jCrVaELHFI0YBjlKC9e/t6ATn7C19y089YY+I53ZBTUZOnFDAunDALgOB4Bl 1JNJcGYhylqGX8PZPxGWf9izq8ib4JfpORQ5g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=npiEoMw1NBAHEmWcSQJzt+lrN2y1/Mmq0X7Sbl5Nd3Q=; b=WqSR1TFezoDgwjAvnrnBeh/K/0kaGJwwkh0IoR7zPba0Cx6t5qrYOGXaFgt78ZS0/s CiJu55YzlV03PIA4VKaT5IIZwKXGxf3DCgNRSYZ6AQ32ifIS4o88kEgBDoDDY9C6/rkP /XKdZbsL3gR4zRT7+6fHVGwbpXZx4caezTpEQbKF+T2QfLeK7S0EGTSC0eFY99Rm94Zu 3BcFuv4FHZf5Xy6bkP5n1Q3s6jDFxIkG3FL0eekor7TfdqL5Ol98Y3UlARAB9L9LXZSQ 3FBLZXcyttpf26ybA96Vh0Gexs2pY2ZtLbI27YSJrOLLk5QlyWuM753emslRw63mzEVs Em1A== X-Gm-Message-State: AOAM5302rOlZ7kQq9F4QvtCgZpP/HIEa5UX8vzcdwgUityWZoFmKpQM7 2sshf5gMlP6+xaUi+a4oMoAlbg== X-Google-Smtp-Source: ABdhPJxHstqBFJY+moBCv3kxzgU0nb4hrm2zlgbLhkcLensIFnyNs2QQfJg7LVYbg1xCfMgskh0P8Q== X-Received: by 2002:a37:ac17:: with SMTP id e23mr11301474qkm.184.1620412294158; Fri, 07 May 2021 11:31:34 -0700 (PDT) Received: from smtpclient.apple (c-24-0-149-15.hsd1.nj.comcast.net. [24.0.149.15]) by smtp.gmail.com with ESMTPSA id z4sm5341057qtq.34.2021.05.07.11.31.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 May 2021 11:31:33 -0700 (PDT) From: Jonathan Lennox Message-Id: <93575A29-792C-405C-8455-F39560A21E2F@8x8.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_925561F4-E5B6-450F-8867-D2473EAEA12E" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Fri, 7 May 2021 14:31:32 -0400 In-Reply-To: Cc: IETF AVTCore WG To: "Murray S. Kucherawy" References: X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [AVTCORE] AD Review of draft-ietf-payload-vp9-12 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2021 18:38:50 -0000 --Apple-Mail=_925561F4-E5B6-450F-8867-D2473EAEA12E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi - sorry for not responding sooner. Responses inline. Do you want me to publish a version -13 with the changes mentioned here? = In the meantime my changes are in the GitHub repo at = https://github.com/juberti/draughts/tree/master/vp9 = . > On Apr 19, 2021, at 6:32 PM, Murray S. Kucherawy = wrote: >=20 > This is my review of draft-ietf-payload-vp9-12. >=20 > Video codecs are not exactly my strong suit, so finding technical = errors wasn't an expected part of my mission here. I'm going on faith = that this is all technically correct, and just looking for editorial or = procedural things. >=20 > -MSK >=20 > -- >=20 > Shepherd writeup: >=20 > * We should probably explain why a document coming out of AVTCORE = bears a name that doesn't start with "draft-ietf-avtcore-...". The = shepherd writeup should mention this. Or if you don't want to do that, = please let me know what the history is there so I can include it in a = note to the IESG. Either in the writeup or in the note is fine, but the history is that = the Payload Working Group was merged back into the AVTCore group in = September 2019, whereas this draft was first adopted as a WG item of the = Payload group in 2015. (Yes, we=E2=80=99ve been very slow about = finishing this draft.) > * The writeup identifies draft-ietf-avtext-lrr as a downward = reference, but that document is in the queue already for Proposed = Standard status, and this one is going for the same, so I don't believe = this is a downward reference (once both are published). > <> > General nits: >=20 > * Referring to an I-D as a "memo" is a little outdated. Suggest = "document" or "specification" instead. Ok. >=20 > Section 1: >=20 > * Should this document obsolete VP8 (RFC 6386)? No, VP8 and VP9 are two different codecs, and they=E2=80=99re both = expected to remain in active use. > Section 3: >=20 > * The Editor's Note seems like it should've been resolved by now. If = no suggestion for improved terminology arrives by the end of IESG = Evaluation, should that paragraph be removed? I=E2=80=99ve kept the clarification (that =E2=80=9CPicture Group=E2=80=9D = and =E2=80=9CGroup of Pictures=E2=80=9D are different), but removed the = request for better terminology. > Section 4.1: >=20 > * For "Timestamp", did you mean to say "alternately" (i.e., every = other one; alternating) or "alternatively" (i.e., presenting a different = choice)? =E2=80=9CAlternatively=E2=80=9D; changed. > Section 4.2: >=20 > * First sentence, "The" shouldn't be capitalized. Ok. >=20 > * The use of CONDITIONALLY RECOMMENDED or CONDITIONALLY REQUIRED is = puzzling because one of them is a BCP 14 word and one isn't, but both = look like they're supposed to be. This might be better described in the = prose for each of these fields, and just use the BCP 14 words here (or = omit them entirely). I=E2=80=99ve made =E2=80=9CConditionally=E2=80=9D only initially = capitalized, and clarified the description of the fields to have = capitalized BCP 14 words. > * The description of PID refers to a "maximum ID", but that's not = specified anywhere. Is it simply the largest PID that will fit in the = available bits, or is there some other maximum to be observed? The maximum that will fit in the available bits; I=E2=80=99ve clarified. >=20 > * For the "D:" bullet, I think "MUST be set to one if current spatial = layer SID frame depends on spatial layer SID-1 frame of the same = picture. MUST only be set to zero if current spatial layer SID frame = does not depend on spatial layer SID-1 frame of the same picture." can = be reduced to "MUST be set to one if and only if the current spatial = layer SID frame depends on spatial layer SID-1 frame of the same = picture." Good improvement. >=20 > Section 6.1: >=20 > * Does the media type's subtype name have to be "VP9", in specifically = that case? No, media subtype names aren=E2=80=99t case-sensitive. Do you think it = would be clearer to write it in lower-case here? > * Per RFC 6838, please change Required Parameters to "N/A" instead of = "None". Ok. > * I think it's unusual for the BCP 14 text to appear in a media type = registration (specifically, the Optional Parameters). You might = consider moving that discussion to some other prose section, and in the = media type registration just list the supported parameters and their = syntaxes. I=E2=80=99ve reorganized this section; I think it generally flows better = now. Thank you for your comments! =E2=80=94=20 Jonathan Lennox jonathan.lennox@8x8.com --Apple-Mail=_925561F4-E5B6-450F-8867-D2473EAEA12E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = - sorry for not responding sooner.  Responses inline.

Do you want me to = publish a version -13 with the changes mentioned here?  In the = meantime my changes are in the GitHub repo at https://github.com/juberti/draughts/tree/master/vp9.

On Apr 19, 2021, at 6:32 PM, Murray S. Kucherawy <superuser@gmail.com>= wrote:

This is my review of = draft-ietf-payload-vp9-12.

Video codecs are not exactly my strong = suit, so finding technical errors wasn't an expected part of my mission = here.  I'm going on faith that this is all technically correct, and = just looking for editorial or procedural things.

-MSK

--

Shepherd writeup:

* We should probably explain why a = document coming out of AVTCORE bears a name that doesn't start with = "draft-ietf-avtcore-...".  The shepherd writeup should mention = this.  Or if you don't want to do that, please let me know what the = history is there so I can include it in a note to the IESG.

Either in the writeup or in the note is fine, but = the history is that the Payload Working Group was merged back into the = AVTCore group in September 2019, whereas this draft was first adopted as = a WG item of the Payload group in 2015.  (Yes, we=E2=80=99ve been = very slow about finishing this draft.)

* The writeup identifies draft-ietf-avtext-lrr as a downward = reference, but that document is in the queue already for Proposed = Standard status, and this one is going for the same, so I don't believe = this is a downward reference (once both are published).
General nits:

* Referring to an I-D as a "memo" is a little outdated.  = Suggest "document" or "specification" = instead.

Ok.

Section 1:

* Should this document obsolete VP8 = (RFC 6386)?

No, VP8 and VP9 are two different codecs, and = they=E2=80=99re both expected to remain in active use.

Section 3:

* The Editor's Note seems like it = should've been resolved by now.  If no suggestion for improved = terminology arrives by the end of IESG Evaluation, should that paragraph = be removed?

I=E2=80=99ve kept the clarification (that = =E2=80=9CPicture Group=E2=80=9D and =E2=80=9CGroup of Pictures=E2=80=9D = are different), but removed the request for better terminology.

Section 4.1:

* For "Timestamp", did you mean to say = "alternately" (i.e., every other one; alternating) or "alternatively" = (i.e., presenting a different = choice)?

=E2=80=9CAlternatively=E2=80=9D; changed.

Section 4.2:

* First sentence, "The" = shouldn't be capitalized.

Ok.

* The use of CONDITIONALLY RECOMMENDED = or CONDITIONALLY REQUIRED is puzzling because one of them is a BCP 14 = word and one isn't, but both look like they're supposed to be.  = This might be better described in the prose for each of these fields, = and just use the BCP 14 words here (or omit them = entirely).

I=E2=80=99ve made =E2=80=9CConditionally=E2=80=9D = only initially capitalized, and clarified the description of the fields = to have capitalized BCP 14 words.

* The description of PID refers to a "maximum ID", but that's = not specified anywhere.  Is it simply the largest PID that will fit = in the available bits, or is there some other maximum to be observed?

The maximum that will fit in the available bits; = I=E2=80=99ve clarified.

* For the "D:" bullet, I think "MUST = be set to one if current spatial layer SID frame depends on spatial = layer SID-1 frame of the same picture. MUST only be set to zero if = current spatial layer SID frame does not depend on spatial layer SID-1 = frame of the same picture." can be reduced to "MUST be set to one if and = only if the current spatial layer SID frame depends on spatial layer = SID-1 frame of the same picture."

Good improvement.


Section 6.1:

* Does the media type's = subtype name have to be "VP9", in specifically that = case?

No, = media subtype names aren=E2=80=99t case-sensitive.  Do you think it = would be clearer to write it in lower-case here?

* Per RFC 6838, please change = Required Parameters to "N/A" instead of = "None".

Ok.

* I think it's unusual for the BCP 14 text to appear in a = media type registration (specifically, the Optional Parameters).  = You might consider moving that discussion to some other prose section, = and in the media type registration just list the supported parameters = and their syntaxes.

I=E2=80=99ve reorganized this section; I think it = generally flows better now.

Thank = you for your comments!

=E2=80=94 
Jonathan = Lennox

= --Apple-Mail=_925561F4-E5B6-450F-8867-D2473EAEA12E-- From nobody Fri May 7 11:39:18 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE8273A2D96; Fri, 7 May 2021 11:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0nw_4Or3Li6; Fri, 7 May 2021 11:38:50 -0700 (PDT) Received: from smtp.egensajt.se (smtp.egensajt.se [194.68.80.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E98D3A2DB8; Fri, 7 May 2021 11:35:55 -0700 (PDT) Received: from [192.168.2.137] (h77-53-37-81.cust.a3fiber.se [77.53.37.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 5B4D320FF0; Fri, 7 May 2021 20:35:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1620412552; bh=SMvvsVL2FA40gNLIWLgrMe/AoZqHO4h5iNa4TQ7yd/c=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=VjBXviRGdM1R6nxPq7MHEx8kIkd1oXEWP5/cRQ1qc79qsHL87xD0OsMtCASQh2Lko tYWKRd+ulp3mnRnBQ3L01PkVk+KSyCCBoXH6M1O5Hno+NFyaF1X7mV4XLC0i1Ut0Pm CK3THlm0wasxX0hhGaUktCOzQwIIpjFwXDVqdt5Q= To: Peter Yee , gen-art@ietf.org Cc: avt@ietf.org, draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org, last-call@ietf.org References: <162027251164.6302.1747673550915835779@ietfa.amsl.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Fri, 7 May 2021 20:35:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <162027251164.6302.1747673550915835779@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: sv Archived-At: Subject: Re: [AVTCORE] Genart last call review of draft-ietf-avtcore-multi-party-rtt-mix-14 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2021 18:38:58 -0000 Continuing with comments and edit proposals from "Nits/editorial comments:" below. Den 2021-05-06 kl. 05:41, skrev Peter Yee via Datatracker: > Reviewer: Peter Yee > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-avtcore-multi-party-rtt-mix-14 > Reviewer: Peter Yee > Review Date: 2021-05-05 > IETF LC End Date: 2021-05-03 > IESG Telechat date: Not scheduled for a telechat > > Summary: This draft specifies updates to RFC 4103 to allow real-time text > mixing for both multiparty-aware and multiparty-unaware participants. It has > some minor issues that should be addressed before publication. [Ready with > issues] > > Major issues: None > > Minor issues: [GH] Covered in a recent response. > > > Nits/editorial comments: > > General: > Change “multi-party” to “multiparty” throughout the document. While we are a > bit inconsistent about that particular hyphenation within the IETF, all major > dictionaries I sampled spell this as a single, non-hyphenated word. [GH] Accepted and done. > > Append a comma after each instance of “e.g.”. [GH] Accepted and done. > > Change “multiparty aware” to “multiparty-aware” throughout the document except > in two cases where you “multiparty awareness”, which should be left alone. > These are located in section 4.2, 1st paragraph, 1st sentence and section 6.1, > 2nd paragraph, 2nd sentence. [GH] Accepted and done. > > Change “fall-back” to “fallback” in a few places in the document. Both uses are > found in the document. [GH] Accepted and done. > Change “RTP-mixer based” to “RTP-mixer-based” throughout the document. [GH] Accepted and done. > > Change “multiparty capable” to “multiparty-capable” throughout the document. [GH] I suggest to change to "multiparty-aware" instead for consistency. > > Delete periods at the end of section/subsection titles, e.g., section 6.2. [GH] Accepted and done. > > Specific: > > Page 1, Abstract, 1st sentence: I’d rewrite it in the active voice as: “This > document provides enhancements for RFC 4103 real-time text mixing suitable for > a centralized conference model that enables source identification and rapidly > interleaved transmission of text from different sources.” [GH] Accepted and done. > > Page 1, Abstract, 3rd paragraph, 1st sentence: insert a hyphen between > “multiparty” and “coded”. [GH] Accepted and done. > > Page 5, 3rd paragraph, 1st sentence: I think I would change “in” to “at”. [GH] Accepted and done. > > Page 5, 7th paragraph, 3rd sentence: delete “any”. Change “way” to “ways”. [GH] Accepted and done. > > Page 6, section 1.1, 2nd paragraph: insert “are” before “as”. [GH] Recently changed to just "are defined in" by proposal in another review. I suggest to keep that. > > Page 6, section 1.1, “WebRTC” term: change “web based” to “web-based”. Insert > “real-time” before “communication”. [GH] Accepted and done. > > Page 6, “DTLS-SRTP” term: delete “stands for security”. Insert “is a DTLS > extension for use with SRTP/SRTCP” before “specified”. [GH] Accepted and done. > > Page 6, “multiparty-aware” term: change “stands for” to “describes”. Append a > comma after “real-time” before “separated”. Append a comma after “source”. [GH] Accepted and done. > > Page 6, “multiparty-unaware”: change “stands for” to “describes”. [GH] Accepted and done.Your use of hyphen in "multiparty-unaware" made me understand that that term also should be hyphenated all through the document. Done. > > Pages 7 and 8: delete the period after each of the non-indented lines, e.g., at > the end of “Multiple RTP streams, one per participant.” [GH] Accepted and done. > > Page 7, 1st block, 4th sentence: change “end to end” to “end-to-end”. [GH] Accepted and done. Done also in one more location in 3.19 inserted in version -16. > > Page 7, 1st block, 11th sentence: append a comma after “participant”. Delete > the following “and”. Insert “with” before “no”. [GH] Accepted and done. > > Page 7, 1st block, 14th sentence: change “implementation” to “implementations” > and delete “technologies” unless you really want the problem is in regards to > technologies and not particular implementations. [GH] Accepted and done, it looks better this way even if the problem may be common in certain implementation technologies. > > Page 7, 1st block 15th sentence: change “made” to “led to”. Insert “being” > before “only”. [GH] Accepted and done. From here all comments are accepted and done as proposed except where a specific answer is provided. > > Page 7, 2nd block, 1st sentence: insert “a” before “shorter”. Insert “the” > before source”. Insert “the” before “CSRC”. Append field after “CSRC”. > > Page 7, 2nd block, 2nd sentence: insert “a” before the quoted “text/t140”. > > Page 7, 2nd block, 3rd sentence: delete the whole sentence. > > Page 7, 2nd block, 6th sentence: move “with” before “receivers”. Insert “having > the” before “default”. > > Page 8, 1st partial block, 2nd full sentence: insert “it” before “corresponds”. > > Page 8, 1st full block, 6th sentence: change “be varying” to “vary”. > > Page 8, 1st full block, 9th sentence: change “while” to “When”. > > Page 9, section 1.3, 1st paragraph, 3rd sentence: change “calltaker” to “call > taker”. Change “observing” to “to observe”. > > Page 11, section 2.4, 3rd paragraph: append a comma after “CSRC-list”. > > Page 12, section 3.1, 4th paragraph: change “From other aspects” to “In other > regards”. > > Page 13, section 3.4, 1st paragraph, 3rd sentence: insert a hyphen between “10” > and “second”. > > Page 13, section 3.4, 1st paragraph, 4th sentence: delete “a” before “good”. > > Page 13, section 3.4, 2nd paragraph, 1st sentence: insert “SHALL be” before > “sent”. Insert “the” before “end”. > > Page 13, section 3.4, 2nd paragraph, 2nd sentence: Append a period at the end > of the sentence. > > Page 13, section 3.4, 3rd paragraph: change “in” to “as”. > > Page 13, section 3.6: insert a hyphen between “locally” and “produced”. Append > “text” after “produced”. > > Page 14, 1st paragraph, 3rd sentence: delete the comma after “T140blocks”. > > Page 14, section 3.10, 1st paragraph after the bullet points, 1st sentence: > insert “the” before “time”. > > Page 15, section 3.11, 2nd paragraph: append a comma after “switch”. Change > “poulated” to “populated”. > > Page 15, section 3.12, 1st paragraph, 1st sentence: insert “the” before “next”. > > Page 15, section 3.12, 1st paragraph, 2nd sentence: insert “the” before “next”. > > Page 15, section 3.12, 2nd paragraph, 2nd sentence: change “number” to “level”. > > Page 16, section 3.14, 1st paragraph, 1st sentence: delete an extraneous space > after “(“. > > Page 16, section 3.14, 1st paragraph, last sentence: insert “self-sourced” > before “data”. Delete “that it is source of itself”. > > Page 16, section 3.16, 1st paragraph, 1st sentence: append a comma after > “CNAME”. > > Page 17, section 3.17.2, 1st paragraph, 1st sentence: insert “The receiver > SHALL monitor”. Change “The” to “the”. Delete “SHALL be monitored”. > > Page 17, section 3.17.2, 2nd paragraph, 2nd sentence: append a comma after > “case”. Insert “the receiver SHALL create” before “a t140block”. Delete “SHALL > be created”. I’m suggesting but not certain that you might want to change “and > assigned” to “associated with”. [GH] Accepted and done, but also "accociated" is changed to "associate it" and "inserted" to "insert it" to match the grammar in the beginning of the sentence. > > Page 17, section 3.17.2, 4th paragraph, 1st sentence: change “if” to “whether” > if you are amenable to that wording. > > Page 18, 2nd paragraph: delete an extraneous blank line before this paragraph. > > Page 18, section 3.18, 1st sentence: insert a hyphen between “10” and “second”. > > Page 19, section 3.19, 1st sentence: insert “the” before “session”. Insert > “the” before “media”. > > Page 19, section 3.19, 2nd sentence: insert “the” before “media”. Consider > deleting “security by”. > > Page 19, section 3.19, 5th sentence: change “is” to “are”. > > Page 20, section 3.21, 4th sentence: append a period after “etc”. > > Page 21, 1st partial paragraph, 1st full sentence: insert “a” before “dropped”. > > Page 21, 1st full paragraph, 1st sentence: delete an extraneous space after > “(“. Where the word “area” occurs, would that make more sense as “buffer” or > “queue”? [GH] Accepted and done. "area" changed to "buffer" only for this occurrance. > > Page 21, 1st full paragraph, 2nd sentence: insert “initial” before the first > “text”. > > Page 22, 1st paragraph, 2nd sentence: change “in” to “due to”. > > Page 22, 2nd paragraph, 1st sentence: insert “packets” before “103”. Delete the > comma after “103”. > > Page 22, 2nd paragraph, 2nd sentence: there appears to be an adverb missing > before “the”. Perhaps “during”? [GH] Accepted and done. "during" used. > > Page 22, 3rd paragraph, 2nd sentence: change “21040” to “21060”. > > Page 22, 4th paragraph, 1st sentence: change “needs” to “need”. > > Page 22, 4th paragraph, 2nd sentence: change “21150” to “21160”. > > Page 23, section 4, 1st paragraph, 2nd sentence: delete “and”. > > Page 23, section 4, 3rd paragraph: consider changing “of” before “the text” to > “conveyed in”. > > Page 24, 1st full paragraph, 3rd sentence: insert “a” before “replacement”. > > Page 24, 1st full paragraph, 4th sentence: change “just” to “the same”. > > Page 26, section 4.2, 3rd paragraph, 2nd sentence: insert a hyphen between > “best” and “effort”. > > Page 26, section 4.2, 4th paragraph, 1st sentence: append a comma after > “simulated”. > > Page 26, section 4.2, 4th paragraph, 4th sentence: change “is depending” to > “depends”. > > Page 26, section 4.2, 4th paragraph, 5th sentence: change “switch” to > “switching”. Append a comma after “can”. Append a comma after “example”. > > Page 26, section 4.2.1, 3rd sentence: append a comma after “keep-alive”. > > Page 27, 5th bullet point: insert “the” before “next”. Change “if even” to > “even if”. Insert “a” between “for” and “word delimiter”. > > Page 28, section 4.2.4, 1st paragraph: insert “the” before “UTF-8”. Change > “transform” to “transformation”. [GH] "Encoding" used instead. It seems commonly used. > > Page 28, section 4.2.4, “BEL”: change the comma after “session” to a period. > Capitalize “provides”. > > Page 28, section 4.2.4, “NEW LINE”, 3rd sentence: insert “the” before “display”. > > Page 28, section 4.2.4, “CR LF”, 1st sentence: delete the comma after > “supported”. > > Page 28, section 4.2.4, “CR LF”, 3rd sentence: insert “the” before “display”. > > Page 28, section 4.2.4, “INT ESC”, 1st sentence: insert “the” before “mode”. > > Page 28, section 4.2.4, “SGR”, 2nd sentence: insert “the” before “rendition”. > > Page 29, 1st partial sentence: insert a hyphen between “256” and “bytes”. Then > change “bytes” to “byte”. > > Page 29, “BOM”, 1st sentence: insert “it” before “SHALL”. [GH] Accepted, but part of the first statement is separated out to a sentence of its own: "  It SHALL be deleted from incoming streams." > > Page 29, “Missing text mark”, 1st sentence: change the comma after “apostrophe > ‘” to a period. Insert “It” before “marks”. Insert “the” before “place”. Insert > “the” before “stream”. > > Page 29, “SGR”, 1st sentence: delete the comma after “(SGR)”. Insert “the” > before “status”. > > Page 29, “SGR”, 2nd sentence: change “originated” to “originating”. > > Page 29, BS, last sentence: change “not” to “be”. > > Page 32, section 6.1, title: drop the “e.g.” in the subsection title. [GH] Not done. Many countries have their own terms for textphones. In USA and a few other countries (Canada, Australia) they are called TTY. That term is not understood in other countries. "Textphone" may not be understood in USA. Therefore I prefer having both the general term and the (e.g., TTYs) in the heading. > > Page 32, section 6.1, 2nd paragraph, parenthetical: perhaps you want “i.e.,” > instead of “e.g.” here given that further down you put “TTYS” in another > parenthetical as though it weren’t just an example but the only exemplar of > this type of device under discussion. [GH] No. I did not mean "i.e.,". "TTY" is just one example with specific technology. So, I suggest to keep this sentence:    "One case that may occur is a gateway to PSTN for communication with textphones (e.g., TTYs)."  While in the other places where (TTY) was mentioned it is deleted with its parenthesis. > > Page 32, section 6.1, 2nd paragraph, last sentence: delete “make”. Change > “adaptions” to “adapt”. Delete “for” before “the functional”. Delete “(TTY)”. [GH] I also needed to insert "to" before "adapt" to make: "This solution makes it possible to adapt    to the functional limitations of the textphone." > > Page 32, section 6.1, 3rd paragraph: delete “(TTYs)”. > > Page 33, 2nd paragraph, 2nd sentence: insert “a” before “two-way”. > > Page 33, 3rd paragraph, 2nd sentence: insert “the” before “NAME”. > > Page 33, section 7: insert a hyphen between “multiparty” and “mixing” in this > one instance of that term. Other uses of the term in the document should not be > hyphenated. > > Page 34, section 8, 1st paragraph: I like the sound of the sentence better if > you swap “valid” and “also”. That’s just me.  [GH] Accepted so that you will like to read it again. > > Page 34, section 8, 3rd paragraph, 1st sentence: insert a space between > “second” and “(“CPS”)”. > > Page 34, section 8, 3rd paragraph, 3rd sentence: insert “an” before “RTP”. > Regarding “excess”: in excess of what? > > Page 35, section 11, 1st paragraph, 1st sentence: append a comma after “pack”. > > Page 35, section 11, 2nd paragraph, 1st sentence: append a comma after “CNAME”. > > Page 35, section 11, 3rd paragraph, 1st sentence: I suggest inserting > “emitting” before “a continuous”. Change the comma after “flow of text” to a > period. Delete the following “or”. Change the rest of that sentence to read > something like: “They may also send text that appears to originate from other > participants.” I rewrote that because the malicious participants don’t > themselves masquerade as text, although that might be a mildly amusing > Halloween costume. > > Page 35, section 11, 4th paragraph: delete one of “section” or “Section”. You > capitalize that term interchangeably, so it’s your choice. > > Page 35, section 12.1 (when discussing -14 only): change “Cucherawy” to > “Kucherawy” unless we’re talking about someone else. Yeah, I know these will > all be deleted upon publication, but it caught my eye. I have not reviewed the > remainder of the change history entries. > > Thanks again for the thorough review. I have next version ready, also including changed caused by security comments and discussed in other mail. Do you want me to submit the new version. Regards Gunnar -- Gunnar Hellström GHAccess gunnar.hellstrom@ghaccess.se From nobody Fri May 7 11:48:51 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA1C3A2DEC for ; Fri, 7 May 2021 11:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9qoJIFkr7Tx for ; Fri, 7 May 2021 11:48:44 -0700 (PDT) Received: from mail-vk1-xa34.google.com (mail-vk1-xa34.google.com [IPv6:2607:f8b0:4864:20::a34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30DAA3A2DE5 for ; Fri, 7 May 2021 11:48:44 -0700 (PDT) Received: by mail-vk1-xa34.google.com with SMTP id s2so316247vkf.13 for ; Fri, 07 May 2021 11:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RnUhT7tz7FzRdgAISAJli3yNlaLeIxqowtH8snfFNJU=; b=MkKWtyQV+j8pN3k2p0fd2prnSZTLItpwfNFeMdn3LtC+9d6dYnVFannD2YMDFZGA7U K5GYxobMvnrj5kM7bu4ElSn0CpBT9j0BfS3N9pDBAC0NL5RSOqrNckNImC4FBMLsotlP J0N5+Dxv72rr0/QU3imA/A00tdQ6JXKpiY3uCUHNNjhXd0kQGMzs6LHbi1zSVz+OP38a C6XMrjYAYGBTRe6jRpsBNthr1bjdDo/8qILl5fo21eCPAu9iHVzkv4B555qwwGWt3WWC 7qIuTfTPUBO64c9fSydqVP4i0jiIbrCSYALQhAzqel3IE4GMuyAzAO0/xbEdHm8f1b0J qIiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RnUhT7tz7FzRdgAISAJli3yNlaLeIxqowtH8snfFNJU=; b=qYNF4Xz7w56YCf/c62GmiCKEyb9MWAMQV+XP0qNEs5QD3c1edkQvMSBXmZARHQXXkz 5PtwbvCslz5dUZGIQWIMBQefJrqhbNF5lmehRRSokhKXQuaI1VvtbZOyPSkQL8STIxjs H3LgSwUTg3I5rIo7Wg+n2yYzMIIEz0B5D2MACqdEzE70ORMcmUxHEPIrPv8/dPsotnAR h3hxlJC26Eoa+AfEpspM5/q7vKJY5B9Ui5+GiEv+iewwP+F5AjVH88xp/lBPhUGLZFhU TYoujh+jhElr2SpW5tVC8MGInK86mXjBxdRRHaGLfKAmEUZbf9jGlcuRqmarhqg+c5Cx tAIg== X-Gm-Message-State: AOAM531cQTr0bjFc8VL5wLtZsA7Qxv+5CP+bJn+MJQ7DgnF1HjpgsyLB b1inqoXID4J/3dyFxAF/fo9SoMMyh+Y5c0STeyg= X-Google-Smtp-Source: ABdhPJyhGf4qmirQcMZrBL0DE0c4oVnKRbkYHaPMcKA168yk2huEBO2dT6A9nlqdx11D3bo8xWyiI7FBeYFYgAK4x5k= X-Received: by 2002:a1f:9345:: with SMTP id v66mr9495030vkd.22.1620413321576; Fri, 07 May 2021 11:48:41 -0700 (PDT) MIME-Version: 1.0 References: <93575A29-792C-405C-8455-F39560A21E2F@8x8.com> In-Reply-To: <93575A29-792C-405C-8455-F39560A21E2F@8x8.com> From: "Murray S. Kucherawy" Date: Fri, 7 May 2021 11:48:30 -0700 Message-ID: To: Jonathan Lennox Cc: IETF AVTCore WG Content-Type: multipart/alternative; boundary="0000000000006c098805c1c1e0bd" Archived-At: Subject: Re: [AVTCORE] AD Review of draft-ietf-payload-vp9-12 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2021 18:48:49 -0000 --0000000000006c098805c1c1e0bd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jonathan, On Fri, May 7, 2021 at 11:31 AM Jonathan Lennox wrote: > Do you want me to publish a version -13 with the changes mentioned here? > In the meantime my changes are in the GitHub repo at > https://github.com/juberti/draughts/tree/master/vp9. > Yes, please. > > Shepherd writeup: > > * We should probably explain why a document coming out of AVTCORE bears a > name that doesn't start with "draft-ietf-avtcore-...". The shepherd > writeup should mention this. Or if you don't want to do that, please let > me know what the history is there so I can include it in a note to the IE= SG. > > > Either in the writeup or in the note is fine, but the history is that the > Payload Working Group was merged back into the AVTCore group in September > 2019, whereas this draft was first adopted as a WG item of the Payload > group in 2015. (Yes, we=E2=80=99ve been very slow about finishing this d= raft.) > Ah, thanks for that. I'll do it in the note. The merger predates the time of most people on the current IESG, so I'm just hoping to head off any questions during IESG Evaluation. No, VP8 and VP9 are two different codecs, and they=E2=80=99re both expected= to > remain in active use. > OK, just checking. > > * The use of CONDITIONALLY RECOMMENDED or CONDITIONALLY REQUIRED is > puzzling because one of them is a BCP 14 word and one isn't, but both loo= k > like they're supposed to be. This might be better described in the prose > for each of these fields, and just use the BCP 14 words here (or omit the= m > entirely). > > > I=E2=80=99ve made =E2=80=9CConditionally=E2=80=9D only initially capitali= zed, and clarified the > description of the fields to have capitalized BCP 14 words. > OK, that at least looks less strange. Fair compromise. > Section 6.1: > > * Does the media type's subtype name have to be "VP9", in specifically > that case? > > > No, media subtype names aren=E2=80=99t case-sensitive. Do you think it w= ould be > clearer to write it in lower-case here? > Not necessarily. Again, just checking; there have been media type applications I've processed in the past that came in in all-caps because the applicant didn't know they're case-insensitive. When the new version appears, I'll send it for Last Call. -MSK --0000000000006c098805c1c1e0bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jonathan,

On Fri, May 7, 2021 at 11:31 AM Jonathan Lennox <jonathan.lennox@8x8.com> wr= ote:
Do you want me to= publish a version -13 with the changes mentioned here?=C2=A0 In the meanti= me my changes are in the GitHub repo at=C2=A0https://github.com/jube= rti/draughts/tree/master/vp9.

Yes, please.



Shepherd writeup:

<= /div>
* We should probably explain why a document coming out of AVTCORE= bears a name that doesn't start with "draft-ietf-avtcore-..."= ;.=C2=A0 The shepherd writeup should mention this.=C2=A0 Or if you don'= t want to do that, please let me know what the history is there so I can in= clude it in a note to the IESG.

=
Either in the writeup or in the note is fine, but the history is= that the Payload Working Group was merged back into the AVTCore group in S= eptember 2019, whereas this draft was first adopted as a WG item of the Pay= load group in 2015. =C2=A0(Yes, we=E2=80=99ve been very slow about finishin= g this draft.)

Ah, = thanks for that.=C2=A0 I'll do it in the note.=C2=A0 The merger predate= s the time of most people on the current IESG, so I'm just hoping to he= ad off any questions during IESG Evaluation.

No, VP8 and VP9 are two different codecs, and they=E2= =80=99re both expected to remain in active use.

OK, just checking.


* The use of CONDITIONALLY RECOMMENDED or CONDITIONALLY REQUIRE= D is puzzling because one of them is a BCP 14 word and one isn't, but b= oth look like they're supposed to be.=C2=A0 This might be better descri= bed in the prose for each of these fields, and just use the BCP 14 words he= re (or omit them entirely).

I=E2=80=99ve made =E2=80=9CConditionally=E2=80=9D only initially capital= ized, and clarified the description of the fields to have capitalized BCP 1= 4 words.

OK, that a= t least looks less strange.=C2=A0 Fair compromise.


Section 6.1:

* Does the media type's subtyp= e name have to be "VP9", in specifically that case?

No, media subtype names aren=E2=80=99t= case-sensitive.=C2=A0 Do you think it would be clearer to write it in lowe= r-case here?

Not ne= cessarily.=C2=A0 Again, just checking; there have been media type applicati= ons I've processed in the past that came in in all-caps because the app= licant didn't know they're case-insensitive.

When the new version appears, I'll send it for Last Call.
=
-MSK
--0000000000006c098805c1c1e0bd-- From nobody Fri May 7 11:54:58 2021 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 297B93A2E2C; Fri, 7 May 2021 11:54:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: avt@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: avt@ietf.org Message-ID: <162041369611.14170.16848622034752180442@ietfa.amsl.com> Date: Fri, 07 May 2021 11:54:56 -0700 Archived-At: Subject: [AVTCORE] I-D Action: draft-ietf-payload-vp9-13.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2021 18:54:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance WG of the IETF. Title : RTP Payload Format for VP9 Video Authors : Justin Uberti Stefan Holmer Magnus Flodman Danny Hong Jonathan Lennox Filename : draft-ietf-payload-vp9-13.txt Pages : 25 Date : 2021-05-07 Abstract: This specification describes an RTP payload format for the VP9 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. It includes provisions for temporal and spatial scalability. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-vp9/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-payload-vp9-13 https://datatracker.ietf.org/doc/html/draft-ietf-payload-vp9-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-vp9-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 7 11:55:59 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139233A2EBB for ; Fri, 7 May 2021 11:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RutlVcwBuY2g for ; Fri, 7 May 2021 11:55:51 -0700 (PDT) Received: from p3plsmtpa06-01.prod.phx3.secureserver.net (p3plsmtpa06-01.prod.phx3.secureserver.net [173.201.192.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D4133A2E75 for ; Fri, 7 May 2021 11:55:49 -0700 (PDT) Received: from spectre ([173.8.184.78]) by :SMTPAUTH: with ESMTPSA id f5dcl6oIfFX8of5dclGibs; Fri, 07 May 2021 11:55:48 -0700 X-CMAE-Analysis: v=2.4 cv=O6f8ADxW c=1 sm=1 tr=0 ts=60958d34 a=PF7/PIuz6ZQ4FM3W1XNKAQ==:117 a=PF7/PIuz6ZQ4FM3W1XNKAQ==:17 a=IkcTkHD0fZMA:10 a=48vgC7mUAAAA:8 a=AQ6hAG61X4OPiL2Yg3MA:9 a=7Zwj6sZBwVKJAoWSPKxL6X1jA+E=:19 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: peter@akayla.com From: "Peter Yee" To: =?UTF-8?Q?'Gunnar_Hellstr=C3=B6m'?= , Cc: , , References: <162027251164.6302.1747673550915835779@ietfa.amsl.com> <32ad9a53-3aec-0a0f-ce77-6a3a79603e91@ghaccess.se> In-Reply-To: <32ad9a53-3aec-0a0f-ce77-6a3a79603e91@ghaccess.se> Date: Fri, 7 May 2021 11:55:57 -0700 Message-ID: <008501d74372$9d96d6c0$d8c48440$@akayla.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHe5XzwqIi7jGcg8PZdzCAF541FQAK4CJdXqrNWzBA= Content-Language: en-us X-CMAE-Envelope: MS4xfFENG9lRdkbWO+8QfzJavGZSd8hUsYCVkMkmJXGu93YgUJLWrfPIrjSCdQ6WvUnGjjhOWDWRRWGsFD/ydHKBf07XX61Ajmohe0RccMG2T2rbOM9TlEXU Gu6jd3QEtdoqcB4h6eTf6C3Sqzmnl/7hrmSjbhf5VW2GNccm6XDi8x8paxhq2iBOBVvvyIpcfI1eUE00KL2dRwXXUsbVRuPI8AP7DuBZkjD+Y6oTpBR+hpbc H1JM702IqhPbf9YHSWBxh4U0hqELMMKWAbXZAmVYc/jt1I/3xwtzraraRJfJf3MfauWgIdieOVipJoa8LFocevF7Af/Eqazmdz0JNpLwZ6Q= Archived-At: Subject: Re: [AVTCORE] Genart last call review of draft-ietf-avtcore-multi-party-rtt-mix-14 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2021 18:55:58 -0000 Thanks for the quick response, Gunnar. I've prefaced my replies below = with [PEY]. -Peter -----Original Message----- From: Gunnar Hellstr=C3=B6m [mailto:gunnar.hellstrom@ghaccess.se]=20 Sent: Thursday, May 06, 2021 2:14 PM To: Peter Yee; gen-art@ietf.org Cc: avt@ietf.org; draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org; = last-call@ietf.org Subject: Re: Genart last call review of = draft-ietf-avtcore-multi-party-rtt-mix-14 Thank you for the thorough review. Please see comments inline. I will split the answers, and start here with answers and change=20 proposals for the minor issues: Den 2021-05-06 kl. 05:41, skrev Peter Yee via Datatracker: > Reviewer: Peter Yee > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-avtcore-multi-party-rtt-mix-14 > Reviewer: Peter Yee > Review Date: 2021-05-05 > IETF LC End Date: 2021-05-03 > IESG Telechat date: Not scheduled for a telechat > > Summary: This draft specifies updates to RFC 4103 to allow real-time = text > mixing for both multiparty-aware and multiparty-unaware participants. = It has > some minor issues that should be addressed before publication. [Ready = with > issues] > > Major issues: None > > Minor issues: > > Page 7, 1st block, 13th sentence: what constitutes a = =E2=80=9Creasonable effort=E2=80=9D? It > might be best to drop this sentence. [GH] This reason is important for the desicion on technology selection. I suggest a change from: "For best deployment opportunity, it should be possible to upgrade=20 existing endpoint solutions to be multi-party aware with a reasonable=20 effort." to "For best deployment opportunity, it should be feasible to upgrade=20 existing endpoint solutions to become multiparty-aware." [PEY] I'm fine with that. > > Page 7, 2nd block, 2nd sentence, =E2=80=9C300 ms=E2=80=9D: would it = make sense to append > =E2=80=9Cperiod=E2=80=9D or =E2=80=9Ctimeout=E2=80=9D after this = value? [GH] I suggest to change from "every 300 ms." to "with 300 ms = intervals." [PEY] Works for me. > > Page 13, section 3.4, 2nd paragraph, 1st sentence: in regards to = =E2=80=9Conly part=E2=80=9D, > how is this calculated? [GH] I suggest to change from "If the "CPS" value is reached, longer=20 transmission intervals SHALL be applied and only part of the text queued = for transmission sent at end of each transmission interval, until the=20 transmission rate falls under the "CPS" value again." to "If the "CPS" value is reached, longer transmission intervals SHALL be=20 applied and only as much of the text queued for transmission sent at end = of each transmission interval that can be allowed without exceeding the=20 "CPS" value, until the transmission rate falls under the "CPS" value=20 again. Division of text for partial transmission MUST then be made at=20 T140block borders. " [PEY] That's clearer. I'd insert "the" before "end". > > Page 15, section 3.12, 2nd paragraph, 1st sentence: The placing of all > available redundant levels in the packet is presumably subject to a = maximum > packet size or the =E2=80=9CCPS=E2=80=9D limit, if there are obnoxious = levels of redundancy > specified? [GH] Thanks, a good observation. It is already covered in section 3.10,=20 but it could be more emphasized there. In 3.12 we are only dealing with=20 the redundancy, which must be possible to send and is not included in=20 the "CPS" value. I suggest that the following part of 3.10 is improved from: "Redundant text SHALL also be included. See Section 3.12" to; "Redundant text SHALL also be included, and the assessment of how much=20 new text can be included within the maximum packet size MUST take into=20 account that the redundancy has priority to be transmitted in its=20 entirety. See Section 3.12." [PEY] That works. > > Page 17, section 3.17.2, 4th paragraph, 2nd sentence: =E2=80=9CSHALL = prefer=E2=80=9D seems odd. > It doesn=E2=80=99t say that the marking will actually be done. = It=E2=80=99s just preferred. If > you=E2=80=99re not going to require the marking in that sentence, then = perhaps change > =E2=80=9CSHALL=E2=80=9D to =E2=80=9CSHOULD=E2=80=9D. [GH] Agreed. Done as proposed. > > Page 19, section 3.20, 2nd paragraph, 2nd sentence: I don=E2=80=99t = find the =E2=80=9Csomething > specific=E2=80=9D particularly enlightening. Like what? An identifier = for the method? [GH] Proposed to be changed from: " In that case, the SDP of the offer will include something specific for that method, = and an answer acknowledging the use of that method would accept it by something specific included in the SDP." to: "In that case, the SDP of the offer will include something specific for that method,=20 e.g. an SDP attribute or another media format. An answer selecting the=20 use of that method would accept it by a corresponding acknowledgement included in the SDP." [PEY] That helps. With a comma after the "e.g.". ;-) > > Page 27, section 4.2.2, 4th paragraph: can you elaborate on these = =E2=80=9CIntegrity > considerations=E2=80=9D? Otherwise, it=E2=80=99s difficult to comply = with the SHALL in any > meaningful way. [GH] The sentence was inserted after discussions with emergency service=20 providers, who had an example that it would be valuable to have a=20 detailed personalized label of an emergency service agent shown to other = agents while a less personal label should be used when sent to the=20 calling users in emergency. The security aspects on the label are quite similar to the security=20 aspects on the elements specified in RFC 4575. Its=20 security aspects are specified in=20 https://tools.ietf.org/html/rfc4575#section-8 You are right that that example contains mainly SHOULD and RECOMMENDED=20 and no SHALL. I suggest changing: "Integrity considerations SHALL be taken when composing the label." to: "Information available to the mixer for composing the label may contain=20 sensitive personal information that SHOULD not be revealed in sessions=20 not securely authenticated and protected. Integrity considerations=20 regarding how much personal information is included in the label SHOULD=20 therefore be taken when composing the label." [PEY] That's much clearer. > > Page 33, 3rd paragraph, 1st sentence: any reason for the change from = =E2=80=9CT.140=E2=80=9D in > the previous and following paragraphs to =E2=80=9Ct140=E2=80=9D in = this one? [GH] No, they should be "T.140 data channels" for all cases in that=20 paragraph. I have changed. > > Page 33, 6th paragraph: how is disappearance determined? [GH]The disappearance may be signaled by the SIP conference system RFC=20 4353, RFC 4575 etc. as a conference notification if that system is used, = or simply by removal of the text media in an RTP session modification.=20 There may also be a malfunction detected by keep-alive transactions not=20 being maintained. I suggest to not detail how it disappears. [PEY] Okay by me if that's well understood in this ecosystem. The verb = disappearance just made it sound somewhat mysterious as opposed to = something that can be signaled. > > Page 35, section 11, 3rd paragraph, 2nd sentence before creating a new = sentence > (see nits, below): I=E2=80=99m having troubles tying the adjective = =E2=80=9Csecure=E2=80=9D to each of > the nouns in the sentence. It works for =E2=80=9Csignaling=E2=80=9D = and perhaps =E2=80=9Cmedia=E2=80=9D, but > for =E2=80=9Cauthentication=E2=80=9D, one sort of assumes that = authentication mechanism is > secure and helping to provide the security. Perhaps you could reword = that > sentence? [GH] I propose to change the sentence from: "Counteractions should be to require secure signaling, media and authentication, and to provide higher level conference functions e.g. for blocking and expelling participants." to: "Counteractions should be to require authentication, secure session=20 signaling and secure media. Higher level conference functions should=20 also be used e.g., for blocking and expelling participants who caused=20 security concerns." [PEY] Yes, I like that. Along with my usual nit about an Oxford comma = after "signaling". And a hyphen between "Higher" and "layer". Sorry, = that's just how my eyes/brain work. ;-) Thanks, Gunnar Hellstrom --=20 Gunnar Hellstr=C3=B6m GHAccess gunnar.hellstrom@ghaccess.se From nobody Fri May 7 11:58:58 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF203A2E5E for ; Fri, 7 May 2021 11:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=8x8.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPZJRTF9pvzd for ; Fri, 7 May 2021 11:58:45 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E87ED3A2E88 for ; Fri, 7 May 2021 11:58:44 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id l129so9521135qke.8 for ; Fri, 07 May 2021 11:58:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=8x8.com; s=googlemail; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=saHE23C9s3G2SgtqxHAEbKxR2y0B2T4+2tb3eC1fO1g=; b=e9h88oIXS+gyHuBe3DV7koumj0bjFszIrIdzJGxewc2AU1LuigR2/nNS1PWyTX/Xto KG/TcPtJJX8aJ0eo7Nie0pDLAdQ7Ou2qrbixHoDv3z+0w+OHUaOO7P4PIu5xNn+iyW9p Z/olFAB2x4d0oZm6BzP089VeAI/Vg5PyNOV7A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=saHE23C9s3G2SgtqxHAEbKxR2y0B2T4+2tb3eC1fO1g=; b=SZsXJKTfpuhm547WdrFeWZwSrVMk/8jWd28rUvvR3csrItIClVBZd1k+TgvH+txEW5 e4rn+VtltwIcMJBdNGwxysm5caBGxXe6olgjWGxNBKFTdLR+XquZViDRSt7leeG0VJec YvTy0KoJHavcGpnHnyscVfDDQJYdAfgwR7NSl7WRiBWWT9ZiZzWQkICUMWs3AeDm/EUo Cgu2xL7jvuFXlsi0xDwYSgCNelRB7g/OWtRP2ONZq6IhIGhSzbkYcyLVmCBR/3Bo7Qhi uZwWvdWaxuxWvpTk96XXsW8zpNbWNxu3/q2ND2wzGntiMRkYwk2by1ilbPemWm+30yAA XyrQ== X-Gm-Message-State: AOAM530Ih9dOzOqy5YaE6B1/kaSww5in+JZqWjS+ou2p35MdNFnQ76Wc rwWwSSzk7wj2HUxk43FwarM+tctyBI8/Ds2I X-Google-Smtp-Source: ABdhPJzDEWC/+bP+YqNQOfOew6WW7drEdYNY9G/aAOWyktczf8sY2XTHBoH7fpA78O/3n6cLYcIZ4g== X-Received: by 2002:a37:6313:: with SMTP id x19mr10928830qkb.65.1620413923125; Fri, 07 May 2021 11:58:43 -0700 (PDT) Received: from smtpclient.apple (c-24-0-149-15.hsd1.nj.comcast.net. [24.0.149.15]) by smtp.gmail.com with ESMTPSA id n16sm5544098qtl.48.2021.05.07.11.58.42 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 May 2021 11:58:42 -0700 (PDT) From: Jonathan Lennox Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Fri, 7 May 2021 14:58:42 -0400 References: <162041369611.14170.16848622034752180442@ietfa.amsl.com> To: IETF AVTCore WG In-Reply-To: <162041369611.14170.16848622034752180442@ietfa.amsl.com> Message-Id: <16EFBCAF-9442-4CA0-91C6-CFE6999DC118@8x8.com> X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [AVTCORE] I-D Action: draft-ietf-payload-vp9-13.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2021 18:58:57 -0000 This version incorporates the changes from A-D review, discussed on this = list. > On May 7, 2021, at 2:54 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Audio/Video Transport Core = Maintenance WG of the IETF. >=20 > Title : RTP Payload Format for VP9 Video > Authors : Justin Uberti > Stefan Holmer > Magnus Flodman > Danny Hong > Jonathan Lennox > Filename : draft-ietf-payload-vp9-13.txt > Pages : 25 > Date : 2021-05-07 >=20 > Abstract: > This specification describes an RTP payload format for the VP9 video > codec. The payload format has wide applicability, as it supports > applications from low bit-rate peer-to-peer usage, to high bit-rate > video conferences. It includes provisions for temporal and spatial > scalability. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-payload-vp9/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-payload-vp9-13 > https://datatracker.ietf.org/doc/html/draft-ietf-payload-vp9-13 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-vp9-13 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt >=20 From nobody Fri May 7 12:14:36 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8B03A2F2B for ; Fri, 7 May 2021 12:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIIiOWOspgB4 for ; Fri, 7 May 2021 12:14:25 -0700 (PDT) Received: from p3plsmtpa12-05.prod.phx3.secureserver.net (p3plsmtpa12-05.prod.phx3.secureserver.net [68.178.252.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E26D63A2EF3 for ; Fri, 7 May 2021 12:14:24 -0700 (PDT) Received: from spectre ([173.8.184.78]) by :SMTPAUTH: with ESMTPSA id f5vbl0tKZ9Nhjf5vcliB5q; Fri, 07 May 2021 12:14:24 -0700 X-CMAE-Analysis: v=2.4 cv=ZI0SJV3b c=1 sm=1 tr=0 ts=60959190 a=PF7/PIuz6ZQ4FM3W1XNKAQ==:117 a=PF7/PIuz6ZQ4FM3W1XNKAQ==:17 a=IkcTkHD0fZMA:10 a=48vgC7mUAAAA:8 a=3QrLPHW8Hgo3wcA5_fIA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: peter@akayla.com From: "Peter Yee" To: =?UTF-8?Q?'Gunnar_Hellstr=C3=B6m'?= , Cc: , , References: <162027251164.6302.1747673550915835779@ietfa.amsl.com> In-Reply-To: Date: Fri, 7 May 2021 12:14:33 -0700 Message-ID: <008601d74375$369cf690$a3d6e3b0$@akayla.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHe5XzwqIi7jGcg8PZdzCAF541FQAJ93OajqrUrizA= Content-Language: en-us X-CMAE-Envelope: MS4xfOzboYZ1SEjLNL01itXAqnLY2e+RxmPyJtDJkptRHysBPVCVZMwVowubDNVIjeIZbZce6auD9HAA1wTRj0cqhyoHa3ELZkQjA0Fy91nwM95rKD4QWZAi Cy780i5OG45tR3Fr5TFVZxw5noZhEs6DgnLI8CptCDAPN6M4IcjYzMcTN6lAfbWV4T8MhS/CaoIWiiregVSRtrbn+BDcJvSP5hWsbPk1+sIMWDZS3+Mf7swH 50LY3z2w0XRUYEs6ypXZVoc8oWf86GRd5+dyuB/nGkh3F6ihB3KUUGt/yEnMt/k23BqEuyVJRTo3MD6k1oFn9HJHCIo2Abor0fjsUXdjUf0= Archived-At: Subject: Re: [AVTCORE] Genart last call review of draft-ietf-avtcore-multi-party-rtt-mix-14 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2021 19:14:31 -0000 Responses prefixed with [PEY] below. Kind regards, -Peter -----Original Message----- From: Gunnar Hellstr=C3=B6m [mailto:gunnar.hellstrom@ghaccess.se]=20 Sent: Friday, May 07, 2021 11:36 AM To: Peter Yee; gen-art@ietf.org Cc: avt@ietf.org; draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org; = last-call@ietf.org Subject: Re: Genart last call review of = draft-ietf-avtcore-multi-party-rtt-mix-14 Continuing with comments and edit proposals from "Nits/editorial=20 comments:" below. Den 2021-05-06 kl. 05:41, skrev Peter Yee via Datatracker: > Reviewer: Peter Yee > Review result: Ready with Issues > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > For more information, please see the FAQ at > . > Document: draft-ietf-avtcore-multi-party-rtt-mix-14 > Reviewer: Peter Yee > Review Date: 2021-05-05 > IETF LC End Date: 2021-05-03 > IESG Telechat date: Not scheduled for a telechat > Summary: This draft specifies updates to RFC 4103 to allow real-time = text > mixing for both multiparty-aware and multiparty-unaware participants. = It has > some minor issues that should be addressed before publication. [Ready = with > issues] > Nits/editorial comments: > Change =E2=80=9Cmultiparty capable=E2=80=9D to = =E2=80=9Cmultiparty-capable=E2=80=9D throughout the document. [GH] I suggest to change to "multiparty-aware" instead for consistency. [PEY] Fine by me. > Page 6, section 1.1, 2nd paragraph: insert =E2=80=9Care=E2=80=9D = before =E2=80=9Cas=E2=80=9D. [GH] Recently changed to just "are defined in" by proposal in another=20 review. I suggest to keep that. [PEY] Agreed.=20 > Page 6, =E2=80=9Cmultiparty-unaware=E2=80=9D: change =E2=80=9Cstands = for=E2=80=9D to =E2=80=9Cdescribes=E2=80=9D. [GH] Accepted and done.Your use of hyphen in "multiparty-unaware" made=20 me understand that that term also should be hyphenated all through the=20 document. Done. [PEY] Yes, I failed to include that hyphenation in the general nits = although I marked all of them in my review copy. > Page 29, =E2=80=9CBOM=E2=80=9D, 1st sentence: insert = =E2=80=9Cit=E2=80=9D before =E2=80=9CSHALL=E2=80=9D. [GH] Accepted, but part of the first statement is separated out to a=20 sentence of its own: " It SHALL be deleted from incoming streams." [PEY] That's fine. I didn't fuss so much over sentence structure for the = definitions. > Page 32, section 6.1, title: drop the =E2=80=9Ce.g.=E2=80=9D in the = subsection title. [GH] Not done. Many countries have their own terms for textphones. In=20 USA and a few other countries (Canada, Australia) they are called TTY.=20 That term is not understood in other countries. "Textphone" may not be=20 understood in USA. Therefore I prefer having both the general term and=20 the (e.g., TTYs) in the heading. [PEY] With that understanding, I'm fine leaving an examples or two in = the body text. As a matter of style, I don't think examples should = appear in the title, but I won't argue the point. It's only style. :-) > Page 32, section 6.1, 2nd paragraph, parenthetical: perhaps you want = =E2=80=9Ci.e.,=E2=80=9D > instead of =E2=80=9Ce.g.=E2=80=9D here given that further down you put = =E2=80=9CTTYS=E2=80=9D in another > parenthetical as though it weren=E2=80=99t just an example but the = only exemplar of > this type of device under discussion. [GH] No. I did not mean "i.e.,". "TTY" is just one example with specific = technology. So, I suggest to keep this sentence: "One case that may occur is a=20 gateway to PSTN for communication with textphones (e.g., TTYs)." While=20 in the other places where (TTY) was mentioned it is deleted with its=20 parenthesis. [PEY] Okay. > Page 32, section 6.1, 2nd paragraph, last sentence: delete = =E2=80=9Cmake=E2=80=9D. Change > =E2=80=9Cadaptions=E2=80=9D to =E2=80=9Cadapt=E2=80=9D. Delete = =E2=80=9Cfor=E2=80=9D before =E2=80=9Cthe functional=E2=80=9D. Delete = =E2=80=9C(TTY)=E2=80=9D. [GH] I also needed to insert "to" before "adapt" to make: "This solution makes it possible to adapt to the functional limitations of the textphone." [PEY] I'm fine with the that sentence. Thanks again for the thorough review. I have next version ready, also=20 including changed caused by security comments and discussed in other = mail. Do you want me to submit the new version. [PEY] If you have no further changes pending from other reviews, it = probably makes sense to submit a new version with everything = incorporated. I admit that I didn't thoroughly check the diffs between = -14 and -16 to see if any of my proposed changes clashed. Regards Gunnar --=20 Gunnar Hellstr=C3=B6m GHAccess gunnar.hellstrom@ghaccess.se From nobody Fri May 7 12:45:18 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFD73A3026; Fri, 7 May 2021 12:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmiFwbCpCBW1; Fri, 7 May 2021 12:45:11 -0700 (PDT) Received: from smtp.egensajt.se (smtp.egensajt.se [193.42.159.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94C03A2DF7; Fri, 7 May 2021 12:42:49 -0700 (PDT) Received: from [192.168.2.137] (h77-53-37-81.cust.a3fiber.se [77.53.37.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 2B918203B4; Fri, 7 May 2021 21:42:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1620416566; bh=wdidVMKJWSKVexboraJE5pKD6DOXtZNiY4rRyR8GyKI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=h1/E99CAM6O0KTe01ODzA47jQENCJvtf6u60N+jgt2gdKi2W0fILtCsJ16njGHvD4 3a0EEX4H3XzWIqWBXsn7372tCMYwjRMACuSrQWU+uVm/bxH4Ezd9Uk2BbJ9snHZklj MG8PA14PtwKa/0Ie/owbJsIp+wnn7KtQX73YaDus= To: Peter Yee , gen-art@ietf.org Cc: last-call@ietf.org, draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org, avt@ietf.org References: <162027251164.6302.1747673550915835779@ietfa.amsl.com> <32ad9a53-3aec-0a0f-ce77-6a3a79603e91@ghaccess.se> <008501d74372$9d96d6c0$d8c48440$@akayla.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <5807a5ac-c350-bb69-2cbe-2ec85125024d@ghaccess.se> Date: Fri, 7 May 2021 21:42:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <008501d74372$9d96d6c0$d8c48440$@akayla.com> Content-Type: multipart/alternative; boundary="------------4EBAB2C1B8B14A0807A4570A" Content-Language: sv Archived-At: Subject: Re: [AVTCORE] [Last-Call] Genart last call review of draft-ietf-avtcore-multi-party-rtt-mix-14 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2021 19:45:17 -0000 This is a multi-part message in MIME format. --------------4EBAB2C1B8B14A0807A4570A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Peter, I have made the extra few adjustments you proposed. For the use of "disappeared", I agree that it is an unusual term in this context. I checked RFC 4575, and there it is said that users "depart" or "disconnect" from a conference. "Disconnect" feels most familiar, so I propose to change the sentence to: "When a participant on the RTP side is disconnected from the multiparty session, the corresponding T.140 data channel(s) SHOULD be closed." Thanks, Gunnar -- Gunnar Hellström GHAccess gunnar.hellstrom@ghaccess.se Den 2021-05-07 kl. 20:55, skrev Peter Yee: > Thanks for the quick response, Gunnar. I've prefaced my replies below with [PEY]. > > -Peter > > -----Original Message----- > From: Gunnar Hellström [mailto:gunnar.hellstrom@ghaccess.se] > Sent: Thursday, May 06, 2021 2:14 PM > To: Peter Yee; gen-art@ietf.org > Cc: avt@ietf.org; draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org; last-call@ietf.org > Subject: Re: Genart last call review of draft-ietf-avtcore-multi-party-rtt-mix-14 > > Thank you for the thorough review. Please see comments inline. > > I will split the answers, and start here with answers and change > proposals for the minor issues: > > Den 2021-05-06 kl. 05:41, skrev Peter Yee via Datatracker: >> Reviewer: Peter Yee >> Review result: Ready with Issues >> >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >> >> For more information, please see the FAQ at >> >> . >> >> Document: draft-ietf-avtcore-multi-party-rtt-mix-14 >> Reviewer: Peter Yee >> Review Date: 2021-05-05 >> IETF LC End Date: 2021-05-03 >> IESG Telechat date: Not scheduled for a telechat >> >> Summary: This draft specifies updates to RFC 4103 to allow real-time text >> mixing for both multiparty-aware and multiparty-unaware participants. It has >> some minor issues that should be addressed before publication. [Ready with >> issues] >> >> Major issues: None >> >> Minor issues: >> >> Page 7, 1st block, 13th sentence: what constitutes a “reasonable effort”? It >> might be best to drop this sentence. > [GH] This reason is important for the desicion on technology selection. > > I suggest a change from: > > "For best deployment opportunity, it should be possible to upgrade > existing endpoint solutions to be multi-party aware with a reasonable > effort." > > to > > "For best deployment opportunity, it should be feasible to upgrade > existing endpoint solutions to become multiparty-aware." > > [PEY] I'm fine with that. > >> Page 7, 2nd block, 2nd sentence, “300 ms”: would it make sense to append >> “period” or “timeout” after this value? > [GH] I suggest to change from "every 300 ms." to "with 300 ms intervals." > > [PEY] Works for me. > >> Page 13, section 3.4, 2nd paragraph, 1st sentence: in regards to “only part”, >> how is this calculated? > [GH] I suggest to change from "If the "CPS" value is reached, longer > transmission intervals SHALL be applied and only part of the text queued > for transmission sent at end of each transmission interval, until the > transmission rate falls under the "CPS" value again." > > to > > "If the "CPS" value is reached, longer transmission intervals SHALL be > applied and only as much of the text queued for transmission sent at end > of each transmission interval that can be allowed without exceeding the > "CPS" value, until the transmission rate falls under the "CPS" value > again. Division of text for partial transmission MUST then be made at > T140block borders. " > > [PEY] That's clearer. I'd insert "the" before "end". > >> Page 15, section 3.12, 2nd paragraph, 1st sentence: The placing of all >> available redundant levels in the packet is presumably subject to a maximum >> packet size or the “CPS” limit, if there are obnoxious levels of redundancy >> specified? > [GH] Thanks, a good observation. It is already covered in section 3.10, > but it could be more emphasized there. In 3.12 we are only dealing with > the redundancy, which must be possible to send and is not included in > the "CPS" value. > > I suggest that the following part of 3.10 is improved from: > > "Redundant text SHALL also be included. See Section 3.12" > > to; > "Redundant text SHALL also be included, and the assessment of how much > new text can be included within the maximum packet size MUST take into > account that the redundancy has priority to be transmitted in its > entirety. See Section 3.12." > > [PEY] That works. > >> Page 17, section 3.17.2, 4th paragraph, 2nd sentence: “SHALL prefer” seems odd. >> It doesn’t say that the marking will actually be done. It’s just preferred. If >> you’re not going to require the marking in that sentence, then perhaps change >> “SHALL” to “SHOULD”. > [GH] Agreed. Done as proposed. >> Page 19, section 3.20, 2nd paragraph, 2nd sentence: I don’t find the “something >> specific” particularly enlightening. Like what? An identifier for the method? > [GH] Proposed to be changed from: > > " In that case, the > SDP of the offer will include something specific for that method, and > an answer acknowledging the use of that method would accept it by > something specific included in the SDP." > > to: > > "In that case, the > SDP of the offer will include something specific for that method, > e.g. an SDP attribute or another media format. An answer selecting the > use of that method would accept it by > a corresponding acknowledgement included in the SDP." > > [PEY] That helps. With a comma after the "e.g.". ;-) > >> Page 27, section 4.2.2, 4th paragraph: can you elaborate on these “Integrity >> considerations”? Otherwise, it’s difficult to comply with the SHALL in any >> meaningful way. > [GH] The sentence was inserted after discussions with emergency service > providers, who had an example that it would be valuable to have a > detailed personalized label of an emergency service agent shown to other > agents while a less personal label should be used when sent to the > calling users in emergency. > > The security aspects on the label are quite similar to the security > aspects on the elements specified in RFC 4575. Its > security aspects are specified in > https://tools.ietf.org/html/rfc4575#section-8 > > You are right that that example contains mainly SHOULD and RECOMMENDED > and no SHALL. > > I suggest changing: > > "Integrity considerations SHALL be taken when composing the label." > > to: > > "Information available to the mixer for composing the label may contain > sensitive personal information that SHOULD not be revealed in sessions > not securely authenticated and protected. Integrity considerations > regarding how much personal information is included in the label SHOULD > therefore be taken when composing the label." > > [PEY] That's much clearer. > >> Page 33, 3rd paragraph, 1st sentence: any reason for the change from “T.140” in >> the previous and following paragraphs to “t140” in this one? > [GH] No, they should be "T.140 data channels" for all cases in that > paragraph. > I have changed. >> Page 33, 6th paragraph: how is disappearance determined? > [GH]The disappearance may be signaled by the SIP conference system RFC > 4353, RFC 4575 etc. as a conference notification if that system is used, > or simply by removal of the text media in an RTP session modification. > There may also be a malfunction detected by keep-alive transactions not > being maintained. I suggest to not detail how it disappears. > > [PEY] Okay by me if that's well understood in this ecosystem. The verb disappearance just made it sound somewhat mysterious as opposed to something that can be signaled. >> Page 35, section 11, 3rd paragraph, 2nd sentence before creating a new sentence >> (see nits, below): I’m having troubles tying the adjective “secure” to each of >> the nouns in the sentence. It works for “signaling” and perhaps “media”, but >> for “authentication”, one sort of assumes that authentication mechanism is >> secure and helping to provide the security. Perhaps you could reword that >> sentence? > [GH] I propose to change the sentence from: > > "Counteractions should be to require > secure signaling, media and authentication, and to provide higher > level conference functions e.g. for blocking and expelling > participants." > > to: > > "Counteractions should be to require authentication, secure session > signaling and secure media. Higher level conference functions should > also be used e.g., for blocking and expelling participants who caused > security concerns." > > [PEY] Yes, I like that. Along with my usual nit about an Oxford comma after "signaling". And a hyphen between "Higher" and "layer". Sorry, that's just how my eyes/brain work. ;-) > > > Thanks, > > Gunnar Hellstrom > -- Gunnar Hellström GHAccess gunnar.hellstrom@ghaccess.se --------------4EBAB2C1B8B14A0807A4570A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Peter,

I have made the extra few adjustments you proposed.

For the use of "disappeared", I agree that it is an unusual term in this context.

I checked RFC 4575, and there it is said that users "depart" or "disconnect" from a conference. "Disconnect" feels most familiar, so I propose to change the sentence to:

"When a participant on the RTP side is disconnected from the multiparty session, the corresponding T.140 data channel(s) SHOULD be closed."

Thanks,

Gunnar

-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se
Den 2021-05-07 kl. 20:55, skrev Peter Yee:
Thanks for the quick response, Gunnar. I've prefaced my replies below with [PEY].

		-Peter

-----Original Message-----
From: Gunnar Hellström [mailto:gunnar.hellstrom@ghaccess.se] 
Sent: Thursday, May 06, 2021 2:14 PM
To: Peter Yee; gen-art@ietf.org
Cc: avt@ietf.org; draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org; last-call@ietf.org
Subject: Re: Genart last call review of draft-ietf-avtcore-multi-party-rtt-mix-14

Thank you for the thorough review. Please see comments inline.

I will split the answers, and start here with answers and change 
proposals for the minor issues:

Den 2021-05-06 kl. 05:41, skrev Peter Yee via Datatracker:

Reviewer: Peter Yee
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-avtcore-multi-party-rtt-mix-14
Reviewer: Peter Yee
Review Date: 2021-05-05
IETF LC End Date: 2021-05-03
IESG Telechat date: Not scheduled for a telechat

Summary: This draft specifies updates to RFC 4103 to allow real-time text
mixing for both multiparty-aware and multiparty-unaware participants. It has
some minor issues that should be addressed before publication. [Ready with
issues]

Major issues: None

Minor issues:

Page 7, 1st block, 13th sentence: what constitutes a “reasonable effort”? It
might be best to drop this sentence.

[GH] This reason is important for the desicion on technology selection.

I suggest a change from:

"For best deployment opportunity, it should be possible to upgrade 
existing endpoint solutions to be multi-party aware with a reasonable 
effort."

to

"For best deployment opportunity, it should be feasible to upgrade 
existing endpoint solutions to become multiparty-aware."

[PEY] I'm fine with that.


Page 7, 2nd block, 2nd sentence, “300 ms”: would it make sense to append
“period” or “timeout” after this value?

[GH] I suggest to change from "every 300 ms." to "with 300 ms intervals."

[PEY] Works for me.


Page 13, section 3.4, 2nd paragraph, 1st sentence: in regards to “only part”,
how is this calculated?

[GH] I suggest to change from "If the "CPS" value is reached, longer 
transmission intervals SHALL be applied and only part of the text queued 
for transmission sent at end of each transmission interval, until the 
transmission rate falls under the "CPS" value again."

to

"If the "CPS" value is reached, longer transmission intervals SHALL be 
applied and only as much of the text queued for transmission sent at end 
of each transmission interval that can be allowed without exceeding the 
"CPS" value, until the transmission rate falls under the "CPS" value 
again. Division of text for partial transmission MUST then be made at 
T140block borders. "

[PEY] That's clearer. I'd insert "the" before "end".


Page 15, section 3.12, 2nd paragraph, 1st sentence: The placing of all
available redundant levels in the packet is presumably subject to a maximum
packet size or the “CPS” limit, if there are obnoxious levels of redundancy
specified?

[GH] Thanks, a good observation. It is already covered in section 3.10, 
but it could be more emphasized there. In 3.12 we are only dealing with 
the redundancy, which must be possible to send and is not included in 
the "CPS" value.

I suggest that the following part of 3.10 is improved from:

"Redundant text SHALL also be included.  See Section 3.12"

to;
"Redundant text SHALL also be included, and the assessment of how much 
new text can be included within the maximum packet size MUST take into 
account that the redundancy has priority to be transmitted in its 
entirety.  See Section 3.12."

[PEY] That works.


Page 17, section 3.17.2, 4th paragraph, 2nd sentence: “SHALL prefer” seems odd.
It doesn’t say that the marking will actually be done. It’s just preferred. If
you’re not going to require the marking in that sentence, then perhaps change
“SHALL” to “SHOULD”.

[GH] Agreed. Done as proposed.

Page 19, section 3.20, 2nd paragraph, 2nd sentence: I don’t find the “something
specific” particularly enlightening. Like what? An identifier for the method?

[GH] Proposed to be changed from:

" In that case, the
    SDP of the offer will include something specific for that method, and
    an answer acknowledging the use of that method would accept it by
    something specific included in the SDP."

to:

"In that case, the
    SDP of the offer will include something specific for that method, 
e.g. an SDP attribute or another media format. An answer selecting the 
use of that method would accept it by
    a corresponding acknowledgement included in the SDP."

[PEY] That helps. With a comma after the "e.g.". ;-)


Page 27, section 4.2.2, 4th paragraph: can you elaborate on these “Integrity
considerations”? Otherwise, it’s difficult to comply with the SHALL in any
meaningful way.

[GH] The sentence was inserted after discussions with emergency service 
providers, who had an example that it would be valuable to have a 
detailed personalized label of an emergency service agent shown to other 
agents while a less personal label should be used when sent to the 
calling users in emergency.

The security aspects on the label are quite similar to the security 
aspects on the <display-text> elements specified in RFC 4575. Its 
security aspects are specified in 
https://tools.ietf.org/html/rfc4575#section-8

You are right that that example contains mainly SHOULD and RECOMMENDED 
and no SHALL.

I suggest changing:

"Integrity considerations SHALL be taken when composing the label."

to:

"Information available to the mixer for composing the label may contain 
sensitive personal information that SHOULD not be revealed in sessions 
not securely authenticated and protected. Integrity considerations 
regarding how much personal information is included in the label SHOULD 
therefore be taken when composing the label."

[PEY] That's much clearer.


Page 33, 3rd paragraph, 1st sentence: any reason for the change from “T.140” in
the previous and following paragraphs to “t140” in this one?

[GH] No, they should be "T.140 data channels" for all cases in that 
paragraph.
I have changed.

Page 33, 6th paragraph: how is disappearance determined?

[GH]The disappearance may be signaled by the SIP conference system RFC 
4353, RFC 4575 etc. as a conference notification if that system is used, 
or simply by removal of the text media in an RTP session modification. 
There may also be a malfunction detected by keep-alive transactions not 
being maintained. I suggest to not detail how it disappears.

[PEY] Okay by me if that's well understood in this ecosystem. The verb disappearance just made it sound somewhat mysterious as opposed to something that can be signaled.

Page 35, section 11, 3rd paragraph, 2nd sentence before creating a new sentence
(see nits, below): I’m having troubles tying the adjective “secure” to each of
the nouns in the sentence. It works for “signaling” and perhaps “media”, but
for “authentication”, one sort of assumes that authentication mechanism is
secure and helping to provide the security. Perhaps you could reword that
sentence?

[GH] I propose to change the sentence from:

"Counteractions should be to require
    secure signaling, media and authentication, and to provide higher
    level conference functions e.g. for blocking and expelling
    participants."

to:

"Counteractions should be to require authentication, secure session 
signaling and secure media. Higher level conference functions should 
also be used e.g., for blocking and expelling participants who caused 
security concerns."

[PEY] Yes, I like that. Along with my usual nit about an Oxford comma after "signaling". And a hyphen between "Higher" and "layer". Sorry, that's just how my eyes/brain work. ;-)


Thanks,

Gunnar Hellstrom


-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se
--------------4EBAB2C1B8B14A0807A4570A-- From nobody Fri May 7 13:07:23 2021 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFDD3A30DA; Fri, 7 May 2021 13:07:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: avt@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: avt@ietf.org Message-ID: <162041804047.26220.6682120542396941061@ietfa.amsl.com> Date: Fri, 07 May 2021 13:07:20 -0700 Archived-At: Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-multi-party-rtt-mix-17.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2021 20:07:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance WG of the IETF. Title : RTP-mixer formatting of multiparty Real-time text Author : Gunnar Hellstrom Filename : draft-ietf-avtcore-multi-party-rtt-mix-17.txt Pages : 47 Date : 2021-05-07 Abstract: This document provides enhancements for RFC 4103 real-time text mixing suitable for a centralized conference model that enables source identification and rapidly interleaved transmission of text from different sources. The intended use is for real-time text mixers and participant endpoints capable of providing an efficient presentation or other treatment of a multiparty real-time text session. The specified mechanism builds on the standard use of the CSRC list in the RTP packet for source identification. The method makes use of the same "text/t140" and "text/red" formats as for two- party sessions. Solutions using multiple RTP streams in the same RTP session are briefly mentioned, as they could have some benefits over the RTP- mixer model. The possibility to implement the solution in a wide range of existing RTP implementations made the RTP-mixer model be selected to be fully specified in this document. A capability exchange is specified so that it can be verified that a mixer and a participant can handle the multiparty-coded real-time text stream using the RTP-mixer method. The capability is indicated by use of an SDP media attribute "rtt-mixer". The document updates RFC 4103 "RTP Payload for Text Conversation". A specification of how a mixer can format text for the case when the endpoint is not multiparty-aware is also provided. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-avtcore-multi-party-rtt-mix-17.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-multi-party-rtt-mix-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 7 13:14:50 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17413A311C; Fri, 7 May 2021 13:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TuExinNipFq; Fri, 7 May 2021 13:14:44 -0700 (PDT) Received: from smtp.egensajt.se (smtp.egensajt.se [193.42.159.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8CB33A3107; Fri, 7 May 2021 13:14:43 -0700 (PDT) Received: from [192.168.2.137] (h77-53-37-81.cust.a3fiber.se [77.53.37.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 2C6D8202E6; Fri, 7 May 2021 22:14:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1620418482; bh=aws9qRbK+Yom/D3o09FJ4A8dQXd5Ywi6HChFKOq28uI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=OKbuN9MOFRl01QNG6Yp3TwjemfutCMBRjIZslyJVOTPIuRSahShGONgB1FmH6l0+s 6U9X2e69ty3x5vjFjLU+zGdPEhHGKdobT/rursa8Jnm1JDFRvudo6M/AVnJcRVm1yD DgjVNMFSukiXShNSPX4ZiLcqJ1KSZSjb2eZ5Hbzs= To: Peter Yee , gen-art@ietf.org Cc: avt@ietf.org, draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org, last-call@ietf.org References: <162027251164.6302.1747673550915835779@ietfa.amsl.com> <008601d74375$369cf690$a3d6e3b0$@akayla.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <4f59f331-ddb7-1862-1a78-9b06327d99db@ghaccess.se> Date: Fri, 7 May 2021 22:14:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <008601d74375$369cf690$a3d6e3b0$@akayla.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: sv Archived-At: Subject: Re: [AVTCORE] Genart last call review of draft-ietf-avtcore-multi-party-rtt-mix-14 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2021 20:14:49 -0000 Version -17 of the draft is submitted, with intention to have all Genart and Secdir review comments resolved. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-avtcore-multi-party-rtt-mix-17.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-multi-party-rtt-mix-17 Regards Gunnar -- Gunnar Hellström GHAccess gunnar.hellstrom@ghaccess.se Den 2021-05-07 kl. 21:14, skrev Peter Yee: > Responses prefixed with [PEY] below. > > Kind regards, > -Peter > > -----Original Message----- > From: Gunnar Hellström [mailto:gunnar.hellstrom@ghaccess.se] > Sent: Friday, May 07, 2021 11:36 AM > To: Peter Yee; gen-art@ietf.org > Cc: avt@ietf.org; draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org; last-call@ietf.org > Subject: Re: Genart last call review of draft-ietf-avtcore-multi-party-rtt-mix-14 > > Continuing with comments and edit proposals from "Nits/editorial > comments:" below. > > Den 2021-05-06 kl. 05:41, skrev Peter Yee via Datatracker: >> Reviewer: Peter Yee >> Review result: Ready with Issues >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >> For more information, please see the FAQ at >> . >> Document: draft-ietf-avtcore-multi-party-rtt-mix-14 >> Reviewer: Peter Yee >> Review Date: 2021-05-05 >> IETF LC End Date: 2021-05-03 >> IESG Telechat date: Not scheduled for a telechat >> Summary: This draft specifies updates to RFC 4103 to allow real-time text >> mixing for both multiparty-aware and multiparty-unaware participants. It has >> some minor issues that should be addressed before publication. [Ready with >> issues] >> Nits/editorial comments: >> Change “multiparty capable” to “multiparty-capable” throughout the document. > [GH] I suggest to change to "multiparty-aware" instead for consistency. > > [PEY] Fine by me. > >> Page 6, section 1.1, 2nd paragraph: insert “are” before “as”. > [GH] Recently changed to just "are defined in" by proposal in another > review. I suggest to keep that. > > [PEY] Agreed. > >> Page 6, “multiparty-unaware”: change “stands for” to “describes”. > [GH] Accepted and done.Your use of hyphen in "multiparty-unaware" made > me understand that that term also should be hyphenated all through the > document. Done. > > [PEY] Yes, I failed to include that hyphenation in the general nits although I marked all of them in my review copy. > >> Page 29, “BOM”, 1st sentence: insert “it” before “SHALL”. > [GH] Accepted, but part of the first statement is separated out to a > sentence of its own: " It SHALL be deleted from incoming streams." > > [PEY] That's fine. I didn't fuss so much over sentence structure for the definitions. > >> Page 32, section 6.1, title: drop the “e.g.” in the subsection title. > [GH] Not done. Many countries have their own terms for textphones. In > USA and a few other countries (Canada, Australia) they are called TTY. > That term is not understood in other countries. "Textphone" may not be > understood in USA. Therefore I prefer having both the general term and > the (e.g., TTYs) in the heading. > > [PEY] With that understanding, I'm fine leaving an examples or two in the body text. As a matter of style, I don't think examples should appear in the title, but I won't argue the point. It's only style. :-) > >> Page 32, section 6.1, 2nd paragraph, parenthetical: perhaps you want “i.e.,” >> instead of “e.g.” here given that further down you put “TTYS” in another >> parenthetical as though it weren’t just an example but the only exemplar of >> this type of device under discussion. > [GH] No. I did not mean "i.e.,". "TTY" is just one example with specific > technology. > > So, I suggest to keep this sentence: "One case that may occur is a > gateway to PSTN for communication with textphones (e.g., TTYs)." While > in the other places where (TTY) was mentioned it is deleted with its > parenthesis. > > [PEY] Okay. > >> Page 32, section 6.1, 2nd paragraph, last sentence: delete “make”. Change >> “adaptions” to “adapt”. Delete “for” before “the functional”. Delete “(TTY)”. > [GH] I also needed to insert "to" before "adapt" to make: > > "This solution makes it possible to adapt > to the functional limitations of the textphone." > > [PEY] I'm fine with the that sentence. > > Thanks again for the thorough review. I have next version ready, also > including changed caused by security comments and discussed in other mail. > > Do you want me to submit the new version. > > [PEY] If you have no further changes pending from other reviews, it probably makes sense to submit a new version with everything incorporated. I admit that I didn't thoroughly check the diffs between -14 and -16 to see if any of my proposed changes clashed. > > > Regards > > Gunnar > -- Gunnar Hellström GHAccess gunnar.hellstrom@ghaccess.se From nobody Fri May 7 14:22:14 2021 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC253A33A0; Fri, 7 May 2021 14:22:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk CC: avt@ietf.org, avtcore-chairs@ietf.org, bernard.aboba@gmail.com, draft-ietf-payload-vp9@ietf.org, superuser@gmail.com Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <162042252846.30357.10570545719536780770@ietfa.amsl.com> Date: Fri, 07 May 2021 14:22:08 -0700 Archived-At: Subject: [AVTCORE] Last Call: (RTP Payload Format for VP9 Video) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2021 21:22:09 -0000 The IESG has received a request from the Audio/Video Transport Core Maintenance WG (avtcore) to consider the following document: - 'RTP Payload Format for VP9 Video' 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-call@ietf.org mailing lists by 2021-05-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification describes an RTP payload format for the VP9 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. It includes provisions for temporal and spatial scalability. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-payload-vp9/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/4496/ https://datatracker.ietf.org/ipr/4497/ https://datatracker.ietf.org/ipr/4491/ https://datatracker.ietf.org/ipr/2593/ From nobody Mon May 10 04:27:46 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464223A1910; Mon, 10 May 2021 04:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blXDyBXy1SSP; Mon, 10 May 2021 04:27:36 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED0BA3A190F; Mon, 10 May 2021 04:27:35 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:909e:dbe3:cb2c:69ef]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 836FB600072; Mon, 10 May 2021 14:27:25 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1620646045; bh=k9jhHdoILrBsEjVmn0FOgQ6H1j7KP9NBujuF7UjeFjY=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=qnLqzImjcSzd3ASGEcXcYig9Iazd7JsyEP4H8kUQ1DCyM0UtqZmmZlZAKLTJeIMWr YeaPL1dRTgj4DUaeRccEuE/wXFUCggZjlrgUDwovJiBSzZdS9bkT2rXLasZ49bRzag WhO/FLHeoBjzCDLQBOUTZdLVO2LgKTBRIpN9h7Vs= From: Lars Eggert Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_D9D956B7-83DF-4655-A00F-1311FDD1969B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Mon, 10 May 2021 14:27:22 +0300 In-Reply-To: <162027251164.6302.1747673550915835779@ietfa.amsl.com> Cc: gen-art@ietf.org, last-call@ietf.org, draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org, avt@ietf.org To: Peter Yee References: <162027251164.6302.1747673550915835779@ietfa.amsl.com> X-Mailer: Apple Mail (2.3654.80.0.2.43) X-MailScanner-ID: 836FB600072.A2AE1 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [AVTCORE] [Last-Call] Genart last call review of draft-ietf-avtcore-multi-party-rtt-mix-14 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2021 11:27:41 -0000 --Apple-Mail=_D9D956B7-83DF-4655-A00F-1311FDD1969B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Peter, thank you for your review. I have entered a No Objection ballot = for this document. Lars On 2021-5-6, at 6:41, Peter Yee via Datatracker = wrote: >=20 > Reviewer: Peter Yee > Review result: Ready with Issues >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-avtcore-multi-party-rtt-mix-14 > Reviewer: Peter Yee > Review Date: 2021-05-05 > IETF LC End Date: 2021-05-03 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: This draft specifies updates to RFC 4103 to allow real-time = text > mixing for both multiparty-aware and multiparty-unaware participants. = It has > some minor issues that should be addressed before publication. [Ready = with > issues] >=20 > Major issues: None >=20 > Minor issues: >=20 > Page 7, 1st block, 13th sentence: what constitutes a =E2=80=9Creasonable= effort=E2=80=9D? It > might be best to drop this sentence. >=20 > Page 7, 2nd block, 2nd sentence, =E2=80=9C300 ms=E2=80=9D: would it = make sense to append > =E2=80=9Cperiod=E2=80=9D or =E2=80=9Ctimeout=E2=80=9D after this = value? >=20 > Page 13, section 3.4, 2nd paragraph, 1st sentence: in regards to = =E2=80=9Conly part=E2=80=9D, > how is this calculated? >=20 > Page 15, section 3.12, 2nd paragraph, 1st sentence: The placing of all > available redundant levels in the packet is presumably subject to a = maximum > packet size or the =E2=80=9CCPS=E2=80=9D limit, if there are obnoxious = levels of redundancy > specified? >=20 > Page 17, section 3.17.2, 4th paragraph, 2nd sentence: =E2=80=9CSHALL = prefer=E2=80=9D seems odd. > It doesn=E2=80=99t say that the marking will actually be done. It=E2=80=99= s just preferred. If > you=E2=80=99re not going to require the marking in that sentence, then = perhaps change > =E2=80=9CSHALL=E2=80=9D to =E2=80=9CSHOULD=E2=80=9D. >=20 > Page 19, section 3.20, 2nd paragraph, 2nd sentence: I don=E2=80=99t = find the =E2=80=9Csomething > specific=E2=80=9D particularly enlightening. Like what? An identifier = for the method? >=20 > Page 27, section 4.2.2, 4th paragraph: can you elaborate on these = =E2=80=9CIntegrity > considerations=E2=80=9D? Otherwise, it=E2=80=99s difficult to comply = with the SHALL in any > meaningful way. >=20 > Page 33, 3rd paragraph, 1st sentence: any reason for the change from = =E2=80=9CT.140=E2=80=9D in > the previous and following paragraphs to =E2=80=9Ct140=E2=80=9D in = this one? >=20 > Page 33, 6th paragraph: how is disappearance determined? >=20 > Page 35, section 11, 3rd paragraph, 2nd sentence before creating a new = sentence > (see nits, below): I=E2=80=99m having troubles tying the adjective = =E2=80=9Csecure=E2=80=9D to each of > the nouns in the sentence. It works for =E2=80=9Csignaling=E2=80=9D = and perhaps =E2=80=9Cmedia=E2=80=9D, but > for =E2=80=9Cauthentication=E2=80=9D, one sort of assumes that = authentication mechanism is > secure and helping to provide the security. Perhaps you could reword = that > sentence? >=20 > Nits/editorial comments: >=20 > General: > Change =E2=80=9Cmulti-party=E2=80=9D to =E2=80=9Cmultiparty=E2=80=9D = throughout the document. While we are a > bit inconsistent about that particular hyphenation within the IETF, = all major > dictionaries I sampled spell this as a single, non-hyphenated word. >=20 > Append a comma after each instance of =E2=80=9Ce.g.=E2=80=9D. >=20 > Change =E2=80=9Cmultiparty aware=E2=80=9D to =E2=80=9Cmultiparty-aware=E2= =80=9D throughout the document except > in two cases where you =E2=80=9Cmultiparty awareness=E2=80=9D, which = should be left alone. > These are located in section 4.2, 1st paragraph, 1st sentence and = section 6.1, > 2nd paragraph, 2nd sentence. >=20 > Change =E2=80=9Cfall-back=E2=80=9D to =E2=80=9Cfallback=E2=80=9D in a = few places in the document. Both uses are > found in the document. >=20 > Change =E2=80=9CRTP-mixer based=E2=80=9D to =E2=80=9CRTP-mixer-based=E2=80= =9D throughout the document. >=20 > Change =E2=80=9Cmultiparty capable=E2=80=9D to = =E2=80=9Cmultiparty-capable=E2=80=9D throughout the document. >=20 > Delete periods at the end of section/subsection titles, e.g., section = 6.2. >=20 > Specific: >=20 > Page 1, Abstract, 1st sentence: I=E2=80=99d rewrite it in the active = voice as: =E2=80=9CThis > document provides enhancements for RFC 4103 real-time text mixing = suitable for > a centralized conference model that enables source identification and = rapidly > interleaved transmission of text from different sources.=E2=80=9D >=20 > Page 1, Abstract, 3rd paragraph, 1st sentence: insert a hyphen between > =E2=80=9Cmultiparty=E2=80=9D and =E2=80=9Ccoded=E2=80=9D. >=20 > Page 5, 3rd paragraph, 1st sentence: I think I would change =E2=80=9Cin=E2= =80=9D to =E2=80=9Cat=E2=80=9D. >=20 > Page 5, 7th paragraph, 3rd sentence: delete =E2=80=9Cany=E2=80=9D. = Change =E2=80=9Cway=E2=80=9D to =E2=80=9Cways=E2=80=9D. >=20 > Page 6, section 1.1, 2nd paragraph: insert =E2=80=9Care=E2=80=9D = before =E2=80=9Cas=E2=80=9D. >=20 > Page 6, section 1.1, =E2=80=9CWebRTC=E2=80=9D term: change =E2=80=9Cweb = based=E2=80=9D to =E2=80=9Cweb-based=E2=80=9D. Insert > =E2=80=9Creal-time=E2=80=9D before =E2=80=9Ccommunication=E2=80=9D. >=20 > Page 6, =E2=80=9CDTLS-SRTP=E2=80=9D term: delete =E2=80=9Cstands for = security=E2=80=9D. Insert =E2=80=9Cis a DTLS > extension for use with SRTP/SRTCP=E2=80=9D before =E2=80=9Cspecified=E2=80= =9D. >=20 > Page 6, =E2=80=9Cmultiparty-aware=E2=80=9D term: change =E2=80=9Cstands = for=E2=80=9D to =E2=80=9Cdescribes=E2=80=9D. Append a > comma after =E2=80=9Creal-time=E2=80=9D before =E2=80=9Cseparated=E2=80=9D= . Append a comma after =E2=80=9Csource=E2=80=9D. >=20 > Page 6, =E2=80=9Cmultiparty-unaware=E2=80=9D: change =E2=80=9Cstands = for=E2=80=9D to =E2=80=9Cdescribes=E2=80=9D. >=20 > Pages 7 and 8: delete the period after each of the non-indented lines, = e.g., at > the end of =E2=80=9CMultiple RTP streams, one per participant.=E2=80=9D >=20 > Page 7, 1st block, 4th sentence: change =E2=80=9Cend to end=E2=80=9D = to =E2=80=9Cend-to-end=E2=80=9D. >=20 > Page 7, 1st block, 11th sentence: append a comma after = =E2=80=9Cparticipant=E2=80=9D. Delete > the following =E2=80=9Cand=E2=80=9D. Insert =E2=80=9Cwith=E2=80=9D = before =E2=80=9Cno=E2=80=9D. >=20 > Page 7, 1st block, 14th sentence: change =E2=80=9Cimplementation=E2=80=9D= to =E2=80=9Cimplementations=E2=80=9D > and delete =E2=80=9Ctechnologies=E2=80=9D unless you really want the = problem is in regards to > technologies and not particular implementations. >=20 > Page 7, 1st block 15th sentence: change =E2=80=9Cmade=E2=80=9D to = =E2=80=9Cled to=E2=80=9D. Insert =E2=80=9Cbeing=E2=80=9D > before =E2=80=9Conly=E2=80=9D. >=20 > Page 7, 2nd block, 1st sentence: insert =E2=80=9Ca=E2=80=9D before = =E2=80=9Cshorter=E2=80=9D. Insert =E2=80=9Cthe=E2=80=9D > before source=E2=80=9D. Insert =E2=80=9Cthe=E2=80=9D before = =E2=80=9CCSRC=E2=80=9D. Append field after =E2=80=9CCSRC=E2=80=9D. >=20 > Page 7, 2nd block, 2nd sentence: insert =E2=80=9Ca=E2=80=9D before the = quoted =E2=80=9Ctext/t140=E2=80=9D. >=20 > Page 7, 2nd block, 3rd sentence: delete the whole sentence. >=20 > Page 7, 2nd block, 6th sentence: move =E2=80=9Cwith=E2=80=9D before = =E2=80=9Creceivers=E2=80=9D. Insert =E2=80=9Chaving > the=E2=80=9D before =E2=80=9Cdefault=E2=80=9D. >=20 > Page 8, 1st partial block, 2nd full sentence: insert =E2=80=9Cit=E2=80=9D= before =E2=80=9Ccorresponds=E2=80=9D. >=20 > Page 8, 1st full block, 6th sentence: change =E2=80=9Cbe varying=E2=80=9D= to =E2=80=9Cvary=E2=80=9D. >=20 > Page 8, 1st full block, 9th sentence: change =E2=80=9Cwhile=E2=80=9D = to =E2=80=9CWhen=E2=80=9D. >=20 > Page 9, section 1.3, 1st paragraph, 3rd sentence: change = =E2=80=9Ccalltaker=E2=80=9D to =E2=80=9Ccall > taker=E2=80=9D. Change =E2=80=9Cobserving=E2=80=9D to =E2=80=9Cto = observe=E2=80=9D. >=20 > Page 11, section 2.4, 3rd paragraph: append a comma after = =E2=80=9CCSRC-list=E2=80=9D. >=20 > Page 12, section 3.1, 4th paragraph: change =E2=80=9C=46rom other = aspects=E2=80=9D to =E2=80=9CIn other > regards=E2=80=9D. >=20 > Page 13, section 3.4, 1st paragraph, 3rd sentence: insert a hyphen = between =E2=80=9C10=E2=80=9D > and =E2=80=9Csecond=E2=80=9D. >=20 > Page 13, section 3.4, 1st paragraph, 4th sentence: delete =E2=80=9Ca=E2=80= =9D before =E2=80=9Cgood=E2=80=9D. >=20 > Page 13, section 3.4, 2nd paragraph, 1st sentence: insert =E2=80=9CSHALL= be=E2=80=9D before > =E2=80=9Csent=E2=80=9D. Insert =E2=80=9Cthe=E2=80=9D before =E2=80=9Cend= =E2=80=9D. >=20 > Page 13, section 3.4, 2nd paragraph, 2nd sentence: Append a period at = the end > of the sentence. >=20 > Page 13, section 3.4, 3rd paragraph: change =E2=80=9Cin=E2=80=9D to = =E2=80=9Cas=E2=80=9D. >=20 > Page 13, section 3.6: insert a hyphen between =E2=80=9Clocally=E2=80=9D = and =E2=80=9Cproduced=E2=80=9D. Append > =E2=80=9Ctext=E2=80=9D after =E2=80=9Cproduced=E2=80=9D. >=20 > Page 14, 1st paragraph, 3rd sentence: delete the comma after = =E2=80=9CT140blocks=E2=80=9D. >=20 > Page 14, section 3.10, 1st paragraph after the bullet points, 1st = sentence: > insert =E2=80=9Cthe=E2=80=9D before =E2=80=9Ctime=E2=80=9D. >=20 > Page 15, section 3.11, 2nd paragraph: append a comma after = =E2=80=9Cswitch=E2=80=9D. Change > =E2=80=9Cpoulated=E2=80=9D to =E2=80=9Cpopulated=E2=80=9D. >=20 > Page 15, section 3.12, 1st paragraph, 1st sentence: insert =E2=80=9Cthe=E2= =80=9D before =E2=80=9Cnext=E2=80=9D. >=20 > Page 15, section 3.12, 1st paragraph, 2nd sentence: insert =E2=80=9Cthe=E2= =80=9D before =E2=80=9Cnext=E2=80=9D. >=20 > Page 15, section 3.12, 2nd paragraph, 2nd sentence: change = =E2=80=9Cnumber=E2=80=9D to =E2=80=9Clevel=E2=80=9D. >=20 > Page 16, section 3.14, 1st paragraph, 1st sentence: delete an = extraneous space > after =E2=80=9C(=E2=80=9C. >=20 > Page 16, section 3.14, 1st paragraph, last sentence: insert = =E2=80=9Cself-sourced=E2=80=9D > before =E2=80=9Cdata=E2=80=9D. Delete =E2=80=9Cthat it is source of = itself=E2=80=9D. >=20 > Page 16, section 3.16, 1st paragraph, 1st sentence: append a comma = after > =E2=80=9CCNAME=E2=80=9D. >=20 > Page 17, section 3.17.2, 1st paragraph, 1st sentence: insert =E2=80=9CTh= e receiver > SHALL monitor=E2=80=9D. Change =E2=80=9CThe=E2=80=9D to =E2=80=9Cthe=E2=80= =9D. Delete =E2=80=9CSHALL be monitored=E2=80=9D. >=20 > Page 17, section 3.17.2, 2nd paragraph, 2nd sentence: append a comma = after > =E2=80=9Ccase=E2=80=9D. Insert =E2=80=9Cthe receiver SHALL create=E2=80=9D= before =E2=80=9Ca t140block=E2=80=9D. Delete =E2=80=9CSHALL > be created=E2=80=9D. I=E2=80=99m suggesting but not certain that you = might want to change =E2=80=9Cand > assigned=E2=80=9D to =E2=80=9Cassociated with=E2=80=9D. >=20 > Page 17, section 3.17.2, 4th paragraph, 1st sentence: change =E2=80=9Cif= =E2=80=9D to =E2=80=9Cwhether=E2=80=9D > if you are amenable to that wording. >=20 > Page 18, 2nd paragraph: delete an extraneous blank line before this = paragraph. >=20 > Page 18, section 3.18, 1st sentence: insert a hyphen between =E2=80=9C10= =E2=80=9D and =E2=80=9Csecond=E2=80=9D. >=20 > Page 19, section 3.19, 1st sentence: insert =E2=80=9Cthe=E2=80=9D = before =E2=80=9Csession=E2=80=9D. Insert > =E2=80=9Cthe=E2=80=9D before =E2=80=9Cmedia=E2=80=9D. >=20 > Page 19, section 3.19, 2nd sentence: insert =E2=80=9Cthe=E2=80=9D = before =E2=80=9Cmedia=E2=80=9D. Consider > deleting =E2=80=9Csecurity by=E2=80=9D. >=20 > Page 19, section 3.19, 5th sentence: change =E2=80=9Cis=E2=80=9D to = =E2=80=9Care=E2=80=9D. >=20 > Page 20, section 3.21, 4th sentence: append a period after =E2=80=9Cetc=E2= =80=9D. >=20 > Page 21, 1st partial paragraph, 1st full sentence: insert =E2=80=9Ca=E2=80= =9D before =E2=80=9Cdropped=E2=80=9D. >=20 > Page 21, 1st full paragraph, 1st sentence: delete an extraneous space = after > =E2=80=9C(=E2=80=9C. Where the word =E2=80=9Carea=E2=80=9D occurs, = would that make more sense as =E2=80=9Cbuffer=E2=80=9D or > =E2=80=9Cqueue=E2=80=9D? >=20 > Page 21, 1st full paragraph, 2nd sentence: insert =E2=80=9Cinitial=E2=80= =9D before the first > =E2=80=9Ctext=E2=80=9D. >=20 > Page 22, 1st paragraph, 2nd sentence: change =E2=80=9Cin=E2=80=9D to = =E2=80=9Cdue to=E2=80=9D. >=20 > Page 22, 2nd paragraph, 1st sentence: insert =E2=80=9Cpackets=E2=80=9D = before =E2=80=9C103=E2=80=9D. Delete the > comma after =E2=80=9C103=E2=80=9D. >=20 > Page 22, 2nd paragraph, 2nd sentence: there appears to be an adverb = missing > before =E2=80=9Cthe=E2=80=9D. Perhaps =E2=80=9Cduring=E2=80=9D? >=20 > Page 22, 3rd paragraph, 2nd sentence: change =E2=80=9C21040=E2=80=9D = to =E2=80=9C21060=E2=80=9D. >=20 > Page 22, 4th paragraph, 1st sentence: change =E2=80=9Cneeds=E2=80=9D = to =E2=80=9Cneed=E2=80=9D. >=20 > Page 22, 4th paragraph, 2nd sentence: change =E2=80=9C21150=E2=80=9D = to =E2=80=9C21160=E2=80=9D. >=20 > Page 23, section 4, 1st paragraph, 2nd sentence: delete =E2=80=9Cand=E2=80= =9D. >=20 > Page 23, section 4, 3rd paragraph: consider changing =E2=80=9Cof=E2=80=9D= before =E2=80=9Cthe text=E2=80=9D to > =E2=80=9Cconveyed in=E2=80=9D. >=20 > Page 24, 1st full paragraph, 3rd sentence: insert =E2=80=9Ca=E2=80=9D = before =E2=80=9Creplacement=E2=80=9D. >=20 > Page 24, 1st full paragraph, 4th sentence: change =E2=80=9Cjust=E2=80=9D= to =E2=80=9Cthe same=E2=80=9D. >=20 > Page 26, section 4.2, 3rd paragraph, 2nd sentence: insert a hyphen = between > =E2=80=9Cbest=E2=80=9D and =E2=80=9Ceffort=E2=80=9D. >=20 > Page 26, section 4.2, 4th paragraph, 1st sentence: append a comma = after > =E2=80=9Csimulated=E2=80=9D. >=20 > Page 26, section 4.2, 4th paragraph, 4th sentence: change =E2=80=9Cis = depending=E2=80=9D to > =E2=80=9Cdepends=E2=80=9D. >=20 > Page 26, section 4.2, 4th paragraph, 5th sentence: change =E2=80=9Cswitc= h=E2=80=9D to > =E2=80=9Cswitching=E2=80=9D. Append a comma after =E2=80=9Ccan=E2=80=9D.= Append a comma after =E2=80=9Cexample=E2=80=9D. >=20 > Page 26, section 4.2.1, 3rd sentence: append a comma after = =E2=80=9Ckeep-alive=E2=80=9D. >=20 > Page 27, 5th bullet point: insert =E2=80=9Cthe=E2=80=9D before = =E2=80=9Cnext=E2=80=9D. Change =E2=80=9Cif even=E2=80=9D to > =E2=80=9Ceven if=E2=80=9D. Insert =E2=80=9Ca=E2=80=9D between = =E2=80=9Cfor=E2=80=9D and =E2=80=9Cword delimiter=E2=80=9D. >=20 > Page 28, section 4.2.4, 1st paragraph: insert =E2=80=9Cthe=E2=80=9D = before =E2=80=9CUTF-8=E2=80=9D. Change > =E2=80=9Ctransform=E2=80=9D to =E2=80=9Ctransformation=E2=80=9D. >=20 > Page 28, section 4.2.4, =E2=80=9CBEL=E2=80=9D: change the comma after = =E2=80=9Csession=E2=80=9D to a period. > Capitalize =E2=80=9Cprovides=E2=80=9D. >=20 > Page 28, section 4.2.4, =E2=80=9CNEW LINE=E2=80=9D, 3rd sentence: = insert =E2=80=9Cthe=E2=80=9D before =E2=80=9Cdisplay=E2=80=9D. >=20 > Page 28, section 4.2.4, =E2=80=9CCR LF=E2=80=9D, 1st sentence: delete = the comma after > =E2=80=9Csupported=E2=80=9D. >=20 > Page 28, section 4.2.4, =E2=80=9CCR LF=E2=80=9D, 3rd sentence: insert = =E2=80=9Cthe=E2=80=9D before =E2=80=9Cdisplay=E2=80=9D. >=20 > Page 28, section 4.2.4, =E2=80=9CINT ESC=E2=80=9D, 1st sentence: = insert =E2=80=9Cthe=E2=80=9D before =E2=80=9Cmode=E2=80=9D. >=20 > Page 28, section 4.2.4, =E2=80=9CSGR=E2=80=9D, 2nd sentence: insert = =E2=80=9Cthe=E2=80=9D before =E2=80=9Crendition=E2=80=9D. >=20 > Page 29, 1st partial sentence: insert a hyphen between =E2=80=9C256=E2=80= =9D and =E2=80=9Cbytes=E2=80=9D. Then > change =E2=80=9Cbytes=E2=80=9D to =E2=80=9Cbyte=E2=80=9D. >=20 > Page 29, =E2=80=9CBOM=E2=80=9D, 1st sentence: insert =E2=80=9Cit=E2=80=9D= before =E2=80=9CSHALL=E2=80=9D. >=20 > Page 29, =E2=80=9CMissing text mark=E2=80=9D, 1st sentence: change the = comma after =E2=80=9Capostrophe > =E2=80=98=E2=80=9D to a period. Insert =E2=80=9CIt=E2=80=9D before = =E2=80=9Cmarks=E2=80=9D. Insert =E2=80=9Cthe=E2=80=9D before = =E2=80=9Cplace=E2=80=9D. Insert > =E2=80=9Cthe=E2=80=9D before =E2=80=9Cstream=E2=80=9D. >=20 > Page 29, =E2=80=9CSGR=E2=80=9D, 1st sentence: delete the comma after = =E2=80=9C(SGR)=E2=80=9D. Insert =E2=80=9Cthe=E2=80=9D > before =E2=80=9Cstatus=E2=80=9D. >=20 > Page 29, =E2=80=9CSGR=E2=80=9D, 2nd sentence: change =E2=80=9Coriginated= =E2=80=9D to =E2=80=9Coriginating=E2=80=9D. >=20 > Page 29, BS, last sentence: change =E2=80=9Cnot=E2=80=9D to =E2=80=9Cbe=E2= =80=9D. >=20 > Page 32, section 6.1, title: drop the =E2=80=9Ce.g.=E2=80=9D in the = subsection title. >=20 > Page 32, section 6.1, 2nd paragraph, parenthetical: perhaps you want = =E2=80=9Ci.e.,=E2=80=9D > instead of =E2=80=9Ce.g.=E2=80=9D here given that further down you put = =E2=80=9CTTYS=E2=80=9D in another > parenthetical as though it weren=E2=80=99t just an example but the = only exemplar of > this type of device under discussion. >=20 > Page 32, section 6.1, 2nd paragraph, last sentence: delete =E2=80=9Cmake= =E2=80=9D. Change > =E2=80=9Cadaptions=E2=80=9D to =E2=80=9Cadapt=E2=80=9D. Delete = =E2=80=9Cfor=E2=80=9D before =E2=80=9Cthe functional=E2=80=9D. Delete = =E2=80=9C(TTY)=E2=80=9D. >=20 > Page 32, section 6.1, 3rd paragraph: delete =E2=80=9C(TTYs)=E2=80=9D. >=20 > Page 33, 2nd paragraph, 2nd sentence: insert =E2=80=9Ca=E2=80=9D = before =E2=80=9Ctwo-way=E2=80=9D. >=20 > Page 33, 3rd paragraph, 2nd sentence: insert =E2=80=9Cthe=E2=80=9D = before =E2=80=9CNAME=E2=80=9D. >=20 > Page 33, section 7: insert a hyphen between =E2=80=9Cmultiparty=E2=80=9D= and =E2=80=9Cmixing=E2=80=9D in this > one instance of that term. Other uses of the term in the document = should not be > hyphenated. >=20 > Page 34, section 8, 1st paragraph: I like the sound of the sentence = better if > you swap =E2=80=9Cvalid=E2=80=9D and =E2=80=9Calso=E2=80=9D. That=E2=80=99= s just me. =EF=81=8A >=20 > Page 34, section 8, 3rd paragraph, 1st sentence: insert a space = between > =E2=80=9Csecond=E2=80=9D and =E2=80=9C(=E2=80=9CCPS=E2=80=9D)=E2=80=9D. >=20 > Page 34, section 8, 3rd paragraph, 3rd sentence: insert =E2=80=9Can=E2=80= =9D before =E2=80=9CRTP=E2=80=9D. > Regarding =E2=80=9Cexcess=E2=80=9D: in excess of what? >=20 > Page 35, section 11, 1st paragraph, 1st sentence: append a comma after = =E2=80=9Cpack=E2=80=9D. >=20 > Page 35, section 11, 2nd paragraph, 1st sentence: append a comma after = =E2=80=9CCNAME=E2=80=9D. >=20 > Page 35, section 11, 3rd paragraph, 1st sentence: I suggest inserting > =E2=80=9Cemitting=E2=80=9D before =E2=80=9Ca continuous=E2=80=9D. = Change the comma after =E2=80=9Cflow of text=E2=80=9D to a > period. Delete the following =E2=80=9Cor=E2=80=9D. Change the rest of = that sentence to read > something like: =E2=80=9CThey may also send text that appears to = originate from other > participants.=E2=80=9D I rewrote that because the malicious = participants don=E2=80=99t > themselves masquerade as text, although that might be a mildly amusing > Halloween costume. >=20 > Page 35, section 11, 4th paragraph: delete one of =E2=80=9Csection=E2=80= =9D or =E2=80=9CSection=E2=80=9D. You > capitalize that term interchangeably, so it=E2=80=99s your choice. >=20 > Page 35, section 12.1 (when discussing -14 only): change = =E2=80=9CCucherawy=E2=80=9D to > =E2=80=9CKucherawy=E2=80=9D unless we=E2=80=99re talking about someone = else. Yeah, I know these will > all be deleted upon publication, but it caught my eye. I have not = reviewed the > remainder of the change history entries. >=20 >=20 >=20 > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call --Apple-Mail=_D9D956B7-83DF-4655-A00F-1311FDD1969B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmCZGJoACgkQVLXDCb9w wVdsEQ/6AqiLAEMd5xZ8NZr/Py/pEYlP+1I2+fh10kw7Kfyk7yO1TzZQjnnYt9TT 3LKenXqbCmdf89kcW+dwAzaeO2eJTYhdOGPOF3BYndEkoP1J/GMeajynX020HsYe 6+nFfnk4pJwcTyTKP8QYdhKG4FLy//vvN82grdNBgQsdITMCCt4eWzSMQ3HQGk4P 8PA7kPtHjniEPjBzCQA/eb1Rw2/93NUSPkhCgrX1zMaaZBP7EHbIiG3NXfM34zB+ UTLrdZUscY68vmtzULhO1T1WlC5QHk0eapQmhA2qmQPSsznPUTwxdWP2fAk6Afww x2QrYV632f905gsDmlTf2PLJD4aeaZN3CWiO/5yRbj5ijYRoQV9PxRWThKXowQdD JDDqYrzthFCi1Gqyog8kGPeLiigAGhPpkvvqIagKy2gHnB9A2fomhhfZIXaPGxgm Qd3toVdhHtoD0WopWCNQ2b85uiEF9KOsIe3wmTUB/VpMq2u/eukz5DMbAYX0Yj6l Y8cA82uwHgdZW8JQVZfTJ1S/6pfzWvt/pZUHYbvF5Xtexlrv3Fl1WdMukorhL9V0 ruBl+kFA0Vw0YK/9Ax4dqQr6mCiShzuuJB5Kem6aE72MoTIou+I+C4vp238XPM65 /8Uk4coEFnIBrxXrq2PEq82J1cmZtHOfLs5xxqn22deZa/Ns1iQ= =7Jdi -----END PGP SIGNATURE----- --Apple-Mail=_D9D956B7-83DF-4655-A00F-1311FDD1969B-- From nobody Mon May 10 14:30:27 2021 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C0E3A2BC6; Mon, 10 May 2021 14:30:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Duke via Datatracker To: "The IESG" Cc: draft-ietf-avtcore-multi-party-rtt-mix@ietf.org, avtcore-chairs@ietf.org, avt@ietf.org, bernard.aboba@gmail.com, bernard.aboba@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Duke Message-ID: <162068222166.24279.17528511733896002331@ietfa.amsl.com> Date: Mon, 10 May 2021 14:30:22 -0700 Archived-At: Subject: [AVTCORE] Martin Duke's No Objection on draft-ietf-avtcore-multi-party-rtt-mix-17: (with COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2021 21:30:23 -0000 Martin Duke has entered the following ballot position for draft-ietf-avtcore-multi-party-rtt-mix-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - It is not completely clear to me what the actions in the case of congestion are. RFC 4103 RECOMMENDS four steps, the first is going from 300 to 500ms. So what is the hiearchy here. My guess is: Step 1. Senders MUST go from 300ms to 2 seconds Step 2. Senders SHOULD (further?) limit the number of characters sent Step 3. Senders SHOULD go from 2 seconds to 5 seconds Step 4. Senders SHOULD exclude nodes from the session Is this correct? - Assuming it is correct, I don't understand the motivation behind the congestion considerations in Section 8. The first and third paragraphs make perfect sense to me. But if the total traffic to a receiver, regardless of the number of senders, remains limited to 1 packet / 300ms, I don't see why you would change the RFC 4103 guidance of 500ms up to 2 seconds. This isn't a DISCUSS because you're welcome to be more conservative, but I would like to understand your reasoning. No need to reply to the comments below: - In (3.16) and (4.2.2), you mention various privacy-sensitive fields and then say "Integrity SHALL be considered..." I think you mean confidentiality? Integrity means the data hasn't been altered by an attacker. - It would be helpful to clarify in this draft that the CPS limit applies only to new, not redundant, text, assuming that is in fact the case. From nobody Wed May 12 14:02:04 2021 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 089AA3A15BC; Wed, 12 May 2021 14:02:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rifaat Shekh-Yusef via Datatracker To: Cc: avt@ietf.org, draft-ietf-payload-vp9.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162085332298.31523.1409717156510655857@ietfa.amsl.com> Reply-To: Rifaat Shekh-Yusef Date: Wed, 12 May 2021 14:02:03 -0700 Archived-At: Subject: [AVTCORE] Secdir last call review of draft-ietf-payload-vp9-13 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2021 21:02:03 -0000 Reviewer: Rifaat Shekh-Yusef Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document describes an RTP payload format for the VP9 video codec. The security consideration section lists a number of RTP documents that deal with the RTP protocol and its security. The section also highlights that the application is the one that is responsible for securing the media. The security consideration section also discusses the potential impact of a corrupted RTP payload on the receiver and indicates that this is unlikely to pose a denial of service threat. This seems reasonable to me. From nobody Thu May 13 08:04:13 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2EC3A0E51 for ; Thu, 13 May 2021 08:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0VF35VCtwQx for ; Thu, 13 May 2021 08:04:07 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B31E3A0127 for ; Thu, 13 May 2021 08:04:07 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id c15so19604729ljr.7 for ; Thu, 13 May 2021 08:04:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=qrqvppsBEixq3FshF+csLIzxVdGGcwP2LUZ42vuWsPM=; b=ESyLdiv28zP0zl09oWs76/wCHx8r+mws8Ea2XLwxBID/9kPApDNYOLGqI5V0HEDXjI ZpQsSJYxUaUam+7FERcYNVzQQYFBc0IVMFpmyCsuXSd91a37xvPxqwSVA0ErsX5eIkpy Tc1CmFxpP5JZMV+Wn+Oy571+edcKUpkZuSQfR8uqAMqstyb29ghrLJZ/PGWNhRFfCS0w fbW4XPKqnnpgVYpU39h8eQhP7+zY52Pf6neJ0Wh9ispY0krbmvb9cdfg24+8Sk7YEhtx 8s6Il6IcuOQWz5fqYSdslgO+gwq8+bf5Ban30n7hmoaunnc+OJlDqWeg2CfM6jk2UB9v Grfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=qrqvppsBEixq3FshF+csLIzxVdGGcwP2LUZ42vuWsPM=; b=haz6PPsR6i0cn3Uw39IO1C1X8CiLPJ70CRVLRtZ7pf6srtH3QokwrAUn5b1mHWfSB0 u28kxRd8cEGMlQN5u0FK3DeTP/sKmVgZfb/vgniQhCTb0Dzyk9ZXgb2o2LDWosaECyKV lo1pCi22wbsp28ukKTd4xXlbdHigyH1Gn4hVxS64DhPFp4I6ZfjDz0a656vh6K+OyBb1 r3QYtqDwROjmomlkvQc3rShopYVYYxZUHRpZI59jGkiS1BjKHpRiw1JBrWK85Q0FPkhK vMvUb5HsZSw9WNdv9nUEw56EfdJ5hlrR7YtkYrU36rtT5mSUg5lyNmZ2HOzW13TM82hG FOrA== X-Gm-Message-State: AOAM530KOyLCFaFUHKAxLA8WQEJwRkXrqUwWG9yaVG1t9fmS0XJdFVqR g9Tm6WHFDI/jXCuS7/3IDd2IIS7bUPTgl/+l7qy6xwd5BZMHng== X-Google-Smtp-Source: ABdhPJzyn8LxMf4LgtkwuKvNeQ5i25MoLaB3Txq9l2C/a+KzEKC3BzyjOTOzcbo8FfnHyQNJi2zutHQYl0Lb2sMj4+I= X-Received: by 2002:a2e:9d43:: with SMTP id y3mr19630064ljj.85.1620918243387; Thu, 13 May 2021 08:04:03 -0700 (PDT) MIME-Version: 1.0 From: Bernard Aboba Date: Thu, 13 May 2021 08:03:53 -0700 Message-ID: To: IETF AVTCore WG Content-Type: multipart/alternative; boundary="0000000000001b6cfb05c237705c" Archived-At: Subject: [AVTCORE] Reminder: Call for Agenda Items: AVTCORE Virtual Interim on May 24, 2021 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2021 15:04:12 -0000 --0000000000001b6cfb05c237705c Content-Type: text/plain; charset="UTF-8" This is a call for Agenda Items for the AVTCORE WG virtual Interim on May 24, 2021 at 18:00 UTC. If you would like time on the agenda, please send email to the Chairs. Details of the meeting are available here:https://datatracker.ietf.org/meeting/interim-2021-avtcore-02/session/avtcore --0000000000001b6cfb05c237705c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
This is a call for Agenda Items=
 for the  AVTCORE WG virtual Interim on May
24, 2021 at 18:00 UTC.  If you would like time on the agenda, please send
email to the Chairs.

Details of the meeting are available here:
https://da=
tatracker.ietf.org/meeting/interim-2021-avtcore-02/session/avtcore
--0000000000001b6cfb05c237705c-- From nobody Mon May 17 07:24:27 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747EE3A39C2; Mon, 17 May 2021 07:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFO65JDAavj8; Mon, 17 May 2021 07:24:20 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2072.outbound.protection.outlook.com [40.107.20.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F4823A39BE; Mon, 17 May 2021 07:24:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VHtDVo9CxG/oycqDXsi7QuNMZ61HGGgS2+8omiPvKxIERKIlW1Qks64xWsM4d1vcQODuPqiX8tKEpRBCjlYPWs/A2TI4rju3cIuokefYAGJJjAhvRiWsbZtkLHvZdG09gtRzRof/KGdqFYaT5K7k15k68AGojWPlb1JhM3xDK9MVLTeesCXWSeZKp5kqmRq7/TFg6dpbiLKEBiVS4OWa8F6GrR+HbDA0N5ull1KaWSvlECyKQACpLoaMFtimjkSTQpHFwNSsLx2+s0blpYAB1DPFMDihhTKUEsThzRdvmiSUYCbwUeqT4YxQ59fi3qi/4vf/AXueIpCIysfKoA51MA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zLiwT+RJE0tCEmmPQxS2B47LrwNcib0lNKVb/uxtqHI=; b=fkyla2qRfX+Sn/3UJ4WB8OdzScTkSKfm+ipYodP/lnrYw0LEzZWzSS0ctlVUj2lVlQ+mx02wjIlql/SIV6o/3lsVFvDvR8tpfW283vWwRVpH+cQVibMv/LT8+eSYGzrS/Xs/EX/jyT7mF2IgOJxpDLHRlGuk1O5SF7e9VBll6P9mwOWw29ItLThO8jxK09MCGGs7RDxSKuzZ5HGfEoWMdPW43reQPiHq46IBhYglURZnNlts2fsk0d183Y2ibAxJU2D5NpbV3GP2oWxMdh7RpbpPryA/0S57nDxCcSQ2zVVc4UZp6H24/4xG33grVJDZwBqyoz8Dal8YRHkHD8u2UA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zLiwT+RJE0tCEmmPQxS2B47LrwNcib0lNKVb/uxtqHI=; b=u64hH3vw4UqoPwiWMWlNvih5HUfryHSow6EoMNRt3SigOjtFMx7eLvJjRbO3+E4Evk2bNZvbWQx/PSQ/hAfgbjzgsmDd3bZ6r2HkeIFBv0nuKS/S2kz8/THnS2CFIXSA2Om4m63pGqsff5Ew6rUlwAsGxG5bvJpbETLIUnVFJ6s= Received: from AM0PR07MB3860.eurprd07.prod.outlook.com (2603:10a6:208:4c::18) by AM0PR07MB5537.eurprd07.prod.outlook.com (2603:10a6:208:10a::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.11; Mon, 17 May 2021 14:24:17 +0000 Received: from AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::b10f:ebc0:80d:db2]) by AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::b10f:ebc0:80d:db2%7]) with mapi id 15.20.4150.017; Mon, 17 May 2021 14:24:17 +0000 From: Christer Holmberg To: IETF AVTCore WG CC: "avtcore-chairs@ietf.org" , "Murray S. Kucherawy" , mmusic Thread-Topic: SDP directorate review of draft-ietf-payload-rtp-jpegxs-13 Thread-Index: AddLKBOH9HzaEV4jTtmQ8TPYzmKsqw== Date: Mon, 17 May 2021 14:24:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [80.248.247.159] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 43214de1-3ddd-41f5-16ae-08d9193f7469 x-ms-traffictypediagnostic: AM0PR07MB5537: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: CZPPy+U3RIa5IRj8Jfbd8fSGQa0bGFkvxCRH7nTa6SBwCmvbwUQHiLEwHD4b9MpImMC3Oo6fBmKKzBQoaO9LYpEWg1qm4gGGX9VOV8tyoDPIwJAf9dAmgYwO8GFw3qJRIbQX43cDR9NzY0p4a3jaEN8bnIViyOjEJTdujJ60eCnA81EvSIqvhk4U5V5UqF8di6lnfm0dMzpPoTFmzXCq1cCqjvwKJ7yM/TETMQLDp+AJiFcF4e46zvHA+xsE58Qq8+h124sTeelt6ZS7fJeyDPNZep02JBv/mTxI3Rjt4FteD7YsEFwO13oyBBlPupuuOoK1xoPEtb2a6bEv4JHf2yFGIJghPjjGAliA8Evp32fbCdYaVszhSnnQxwlnh5Kw3uhU8Q/hfrp6DTFv37bP5C4ik8ICLmFNdNr3jekqkQRk3JsXnQq6EMW5QIA/1QM2MBi6DPIE8mUiqD01G1cDUR2MNHkWNUBBU+mzHKvnF17v7FTQ4+xx2KWprnhymemzNadUyfHchBlkauIdzUBv7LEkaz3KUGC2Gc9PN+OrmMw+muErCyD+vTQZvQyL2daVFbFswva9446uW6uPfFWzdOqEEXS1UDkjk2OhkPcw8gc= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3860.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(366004)(396003)(376002)(39860400002)(136003)(4326008)(7696005)(38100700002)(122000001)(86362001)(55016002)(9686003)(8936002)(8676002)(6506007)(44832011)(478600001)(54906003)(186003)(33656002)(5660300002)(71200400001)(6916009)(52536014)(64756008)(66476007)(26005)(76116006)(66946007)(2906002)(66446008)(66556008)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?A+jfp10uOqH1NqGWmWi+AVAkHzibSL8cTgqGY0YlAXiVPKAN3mFEKUjjXfoV?= =?us-ascii?Q?gR5du4scmET7J8fX6ez/VlgmW6EVmzOTmtkO3ady9TrooIBjEEJZcRbBfaT5?= =?us-ascii?Q?uoG74i7b60MlRcog6wTHZ6b/KcoZQ6+wn4JyoH4ps6chAiyfAbO3/EKO7gSx?= =?us-ascii?Q?mYmtEkJDwVE3eeMuuA4MFWlaUuyd+W7kW95Z4s1DhfqOJMWCuXU3MXSzUvRL?= =?us-ascii?Q?NTTaUknMuEyzlLCf3vvAqZCm3q6zeu2Q3yqF1M4/YqQn23tX5xjPYH3b7ION?= =?us-ascii?Q?lExwgiO0Zyfc8MEH0ozalNvtNdf4EYJsm1n5chxdTeUKtnOZpPdUQL0KWQQE?= =?us-ascii?Q?X1wAE4qU6UTRCXTARqpC6smFI0B1xuvPADuSerjWAUvu56dIBzjC6yW/sl1j?= =?us-ascii?Q?OKRPA0QVtBqdWLbgQ9nOM+58XLfOIPHAdq59NpZzN4b8nJfssrRCd4cGBLU3?= =?us-ascii?Q?6a/7kKiW3kgINdLkVAVv21V/Ey+8HabWyxx26J5k29U7Pd2KBQpU3jd1HZjB?= =?us-ascii?Q?Opg0GRuohc6sk1SQgOyx+V785g2YptJxD+PR3tX+RSciZviVx6MR7xd4ceiD?= =?us-ascii?Q?ygFL/VzXvhQjkFJYUlfvAG1kygZ20kKlZVsmJKgAfGOodfzmlnc4vHNBFPK8?= =?us-ascii?Q?LuIX70CGUgXF+51pfDIOKC6kmS7SwR48rvD2l0wsVI+xNl6SSuv2smFE0sul?= =?us-ascii?Q?SQyew7EDnJs/HggDVm0KvRbeYjzAR4C8s6U/BXP9BKEsAkfKaOre18AlLZxf?= =?us-ascii?Q?G6nqH48fKApP4jwlcBn0kQVyH8agSuNaYFspkPQMyeUtUCO00/OyvBn015NS?= =?us-ascii?Q?s8FC+jeZT328144YYVuhg0vo8J9fEBguistOLKw9jGlJozvLNF2bXMgQeigl?= =?us-ascii?Q?n8PH2VxQUv06R5CmgnJnL46w4rZ+8FS0Yxvw5TRyGRDnoxyhXwUVUm0Q6ViY?= =?us-ascii?Q?7jcP5sXPDCCkgereYhcv8BAPWsk9lw6BHqt85cCzRGqpZwJdCoOlIqUP04hV?= =?us-ascii?Q?P/QdNq9JZF1O6TeO/+tXLfVH9SjEWW3LSA7iS3WcXFzjqgKIhNt9CkJl9+0b?= =?us-ascii?Q?eTJdUlOHs1diiCkestG2bLcZv9HC1WcrccgLwSLKqQ8HPVk0J04ERQy3UW2Y?= =?us-ascii?Q?MJcH7f6yJaXtVP2zddefRdGFD4k+0YjZbg4JxLO70TJqUvAq5hJMaZ0bBafd?= =?us-ascii?Q?z2imPF1s2fb99+7y9LcRl5V6HvE+9WtWf8Q37yx8cNdKLbOhtBIF7HjSxGSe?= =?us-ascii?Q?7y93tzj4BqGLO0av75gfFjDeHO2DtGXPg6kSoh/fGPIfNinzvI6yI6ZTPNCa?= =?us-ascii?Q?q2QxVSnvftJbT8yMZg+nK6Gz?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR07MB38605C82DE3B4A8F677C8557932D9AM0PR07MB3860eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB3860.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 43214de1-3ddd-41f5-16ae-08d9193f7469 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2021 14:24:17.5574 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 28u8Wv7ETfdgOZyLS76a7qJZVzrUjGavKWA3ZBa/spF3xxu89e8XVgQBk2MMhlXSQOPTsGYiUpci0ynlZhuVrkzz2x5+trSnciZXMgjbL4k= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5537 Archived-At: Subject: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2021 14:24:26 -0000 --_000_AM0PR07MB38605C82DE3B4A8F677C8557932D9AM0PR07MB3860eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have performed the SDP directorate review of draft-ietf-payload-rtp-jpegx= s-13. Regards, Christer ---- Q.1 I suggest converting section 7.2 to a separate main section, and change the= name to "SDP Offer/Answer Considerations". I don't think we need to consid= er other SDP usage than Offer/Answer. Q.2. Regarding section 7.2.1.: "A Session Description Protocol (SDP) [RFC8866] media description SHALL= be created for each RTP stream." This sentence is not needed. "The information carried in the media type specification of Section 7.1 has a specific mapping to the SDP fields, used to describe RTP sessions. This information is redundant with the information found in the payload data (namely, in the JPEG XS header segment) and SHALL be consistent with it." In SDP offer/answer, you typically indicate what you are willing to RECEIVE= . In this case it seems like you indicate what you are going to SEND. Is th= ere a reason for that? I guess that impacts Section 7.2.3 too. Q.3. Regarding Section 7.2.3.: "All parameters must be supported by both sides," In Section 7.2.1 you say that the receiver shall ignore unrecognized parame= ters. I ASSUME that you mean that the all the parameter defined in Section = 7.2.1. "i.e. the answerer SHALL either maintain all parameters or remove the= media format (payload type) completely if one or more of the parameter values are not supported." I don't understand what this mean. According to Section 7.2.1, some of the = parameters are OPTIONAL. Is the answerer only allowed to reply with paramet= ers that were present in the offer? --_000_AM0PR07MB38605C82DE3B4A8F677C8557932D9AM0PR07MB3860eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have performed the SDP direct= orate review of draft-ietf-payload-rtp-jpegxs-13.

 

Regards,

 

Christer

 

----

 

Q.1

 

I suggest converting section 7.= 2 to a separate main section, and change the name to "SDP Offer/Answer= Considerations". I don't think we need to consider other SDP usage th= an Offer/Answer.

 

 

Q.2. Regarding section 7.2.1.:<= o:p>

 

 

    "A Sess= ion Description Protocol (SDP) [RFC8866] media description SHALL be created= for each RTP stream."

 

This sentence is not needed.

 

 

     "= The information carried in the media type specification of

      = Section 7.1 has a specific mapping to the SDP fields, used to

      = describe RTP sessions.  This information is redundant with the

      = information found in the payload data (namely, in the JPEG XS header

      = segment) and SHALL be consistent with it."

 

In SDP offer/answer, you typica= lly indicate what you are willing to RECEIVE. In this case it seems like yo= u indicate what you are going to SEND. Is there a reason for that? I guess = that impacts Section 7.2.3 too.

 

 

Q.3. Regarding Section 7.2.3.:<= o:p>

 

     "= All parameters must be supported by both sides,"

 

In Section 7.2.1 you say that t= he receiver shall ignore unrecognized parameters. I ASSUME that you mean th= at the all the parameter defined in Section 7.2.1.

 

      = "i.e. the answerer SHALL either maintain all parameters or remove the = media format (payload

     &= nbsp; type) completely if one or more of the parameter values are not<= /o:p>

     &= nbsp; supported."

 

I don't understand what this me= an. According to Section 7.2.1, some of the parameters are OPTIONAL. Is the= answerer only allowed to reply with parameters that were present in the of= fer?

--_000_AM0PR07MB38605C82DE3B4A8F677C8557932D9AM0PR07MB3860eurp_-- From nobody Mon May 17 12:21:27 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504483A0E6A for ; Mon, 17 May 2021 12:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aALyMkDZ4PQ3 for ; Mon, 17 May 2021 12:21:23 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D1FA3A0E67 for ; Mon, 17 May 2021 12:21:23 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id z13so10468558lft.1 for ; Mon, 17 May 2021 12:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=UAI6zQW1L1cD2kheG0X/vGHreWaxpU6ses+DjFlPEZ4=; b=gTrNfoOyS4wVx6O1RxWXak/haqFZLr1hxKmGreO1nRCJXzhgOROxTsOQYCrjFn5GB/ X5t8ffoTI/fORkeSh9V8SkuLxH4A0wyHiIFUi6IjruPsf8uOTx55VxernhZ/S5LaNhZT L68MyCn1AGB5a7qoGYnJfjaebML6VDPXjI1NOjMxPS1x9JRCk2hPYz8gNPH3QBqIPu3r erYBYFowQG0DGcM3hoce5ytN2AXpkV/Q+N8Gwu+9mL4u8YjuYbgjGyEaBma7H3Ox7caF c2KjXt/bQ3UIEXthfGI4vCbWRoR5XCr24FNCpk4CwYny8zQipTF2zch7xVhg3I17RY8Q GO+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UAI6zQW1L1cD2kheG0X/vGHreWaxpU6ses+DjFlPEZ4=; b=F4z4S5UYGJT1eIcpjZ6mg3YAERl/Kyk7i9Qa3NGXDfKsTwxdQbsWeqidjytZH7XMBI 814FkipPK26r/74/irWBlSXGFUq1PJDNdYHPmZkwcp+oIdbBfzd8nW0ClaW17pmWznRJ 8MOr4Rfh4lT6sH23JGq44o6inCcNwHef2JI8rJQAgTtsCOWcokEXqgYyzJ2faPBdk5XY 1kS+4vif2aCjhhrDxsJ4ZMzc/TZlYFUfG4+TspJuwLQOs5ZQlyqqD9zDuTu+V1lFTWXu taRQdbFNX7vJ4oX1SS8wbXge2dYEacWAZxn2YK1n/0//tKTpTVQ1enMjqA/RxI4G+rDB sRMQ== X-Gm-Message-State: AOAM530vIoMdxmEhwvtS06stPHQ2ffJHOCaJVKrO4mGXkElR9j6hGQ3l HB3DaNrXvXv1Y9DXwh9CWgrucqIG1OjjQczaAsRz5qnI8Vo/ag== X-Google-Smtp-Source: ABdhPJzW/TFBAVNGsM0/y+AgCqIwfakRj+3Cang+ZfDX5wYWi4hdLwE8SiJHp0cXkcivSgvQAl95u/z7Bo9jsIx/Cfw= X-Received: by 2002:ac2:5faa:: with SMTP id s10mr964691lfe.48.1621279279829; Mon, 17 May 2021 12:21:19 -0700 (PDT) MIME-Version: 1.0 From: Bernard Aboba Date: Mon, 17 May 2021 12:21:09 -0700 Message-ID: To: IETF AVTCore WG Content-Type: multipart/alternative; boundary="0000000000008e556205c28b7fa8" Archived-At: Subject: [AVTCORE] Virtual Interim Agenda X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2021 19:21:27 -0000 --0000000000008e556205c28b7fa8 Content-Type: text/plain; charset="UTF-8" We have a draft agenda for the AVTCORE WG Virtual Interim that will take place on Monday, May 24: Agenda interim-2021-avtcore-02: Mon 11:00 (ietf.org) If you'd like to have time on the agenda, please send email to the Chairs ASAP. --0000000000008e556205c28b7fa8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We have a draft agenda for the AVTCORE WG= Virtual Interim that will take place on Monday, May 24:=C2=A0
If you'd like to have time on the agenda, please send email= to the Chairs ASAP.=C2=A0


--0000000000008e556205c28b7fa8-- From nobody Mon May 17 14:15:47 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA633A4535; Mon, 17 May 2021 14:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UenGAetHW9ju; Mon, 17 May 2021 14:15:40 -0700 (PDT) Received: from smtp.egensajt.se (smtp.egensajt.se [193.42.159.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 337D13A453A; Mon, 17 May 2021 14:15:39 -0700 (PDT) Received: from [192.168.2.137] (h77-53-37-81.cust.a3fiber.se [77.53.37.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 5902620199; Mon, 17 May 2021 23:15:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1621286136; bh=2pUAAGFRFzA8aPPOnNpIqlb93V/6pgaGzxnzow3gL4o=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=xv9BxyrFYldlzCh0/wqL27po79w/jTSTS5NIHeXZeacUifY0S4Vj+W3lWwUlAFNMF ibZBqnEboUPDX7Vy4aY3QU0qkImSRaJVmtHDusQeY/49te+ullvJXDqF01j6hmlThe Q2Rk5pYqyunGZotTEmYmkUAkDfxw/e/CB8oNkXms= To: Martin Duke , The IESG Cc: avtcore-chairs@ietf.org, draft-ietf-avtcore-multi-party-rtt-mix@ietf.org, avt@ietf.org References: <162068222166.24279.17528511733896002331@ietfa.amsl.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Mon, 17 May 2021 23:15:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <162068222166.24279.17528511733896002331@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: sv Archived-At: Subject: Re: [AVTCORE] Martin Duke's No Objection on draft-ietf-avtcore-multi-party-rtt-mix-17: (with COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2021 21:15:46 -0000 Martin, Thanks for the review, Please see my responses inline. Den 2021-05-10 kl. 23:30, skrev Martin Duke via Datatracker: > Martin Duke has entered the following ballot position for > draft-ietf-avtcore-multi-party-rtt-mix-17: No Objection > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > - It is not completely clear to me what the actions in the case of congestion > are. RFC 4103 RECOMMENDS four steps, the first is going from 300 to 500ms. So > what is the hiearchy here. My guess is: > > Step 1. Senders MUST go from 300ms to 2 seconds > Step 2. Senders SHOULD (further?) limit the number of characters sent > Step 3. Senders SHOULD go from 2 seconds to 5 seconds > Step 4. Senders SHOULD exclude nodes from the session > > Is this correct? > > - Assuming it is correct, I don't understand the motivation behind the > congestion considerations in Section 8. > > The first and third paragraphs make perfect sense to me. But if the total > traffic to a receiver, regardless of the number of senders, remains limited to > 1 packet / 300ms, I don't see why you would change the RFC 4103 guidance of > 500ms up to 2 seconds. This isn't a DISCUSS because you're welcome to be more > conservative, but I would like to understand your reasoning. [GH] First, I should clarify that the values are per source in the communication to one receiver. You are right that it is not very logical to require an increase to a fixed time of 2 seconds. It does not help much, and the third action is anyway according to RFC 4103 an increase to an interval between 0.5 and 5 seconds. Therefore, I suggest to replace the second sentence of section 8, so that the section begins: "The congestion considerations and recommended actions from [RFC4103] are also valid in multiparty situations. The time values SHALL then be applied per source of text sent to a receiver." > > No need to reply to the comments below: > > - In (3.16) and (4.2.2), you mention various privacy-sensitive fields and then > say "Integrity SHALL be considered..." I think you mean confidentiality? > Integrity means the data hasn't been altered by an attacker. [GH] Right, I meant "confidentiality". Modified. > > - It would be helpful to clarify in this draft that the CPS limit applies only > to new, not redundant, text, assuming that is in fact the case. [GH] Thanks, yes. I propose to insert the following sentence after the first sentence in section 3.22: "The actual rate is calculated without regard to any redundant text transmission and is in the multiparty case evaluated for all sources contributing to transmission to a receiver." [GH] I will submit version -18 with the changes indicated above, together with edits because of Lars Eggert's nit findings, but am prepared to do further changes if needed on the congestion consideration wording. Thanks, Gunnar > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt -- Gunnar Hellstrm GHAccess gunnar.hellstrom@ghaccess.se From nobody Mon May 17 14:24:32 2021 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5CD3A4579; Mon, 17 May 2021 14:24:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: avt@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.29.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: avt@ietf.org Message-ID: <162128667092.17269.17315209040981379787@ietfa.amsl.com> Date: Mon, 17 May 2021 14:24:30 -0700 Archived-At: Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-multi-party-rtt-mix-18.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2021 21:24:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance WG of the IETF. Title : RTP-mixer formatting of multiparty Real-time text Author : Gunnar Hellstrom Filename : draft-ietf-avtcore-multi-party-rtt-mix-18.txt Pages : 47 Date : 2021-05-17 Abstract: This document provides enhancements for RFC 4103 real-time text mixing suitable for a centralized conference model that enables source identification and rapidly interleaved transmission of text from different sources. The intended use is for real-time text mixers and participant endpoints capable of providing an efficient presentation or other treatment of a multiparty real-time text session. The specified mechanism builds on the standard use of the CSRC list in the RTP packet for source identification. The method makes use of the same "text/t140" and "text/red" formats as for two- party sessions. Solutions using multiple RTP streams in the same RTP session are briefly mentioned, as they could have some benefits over the RTP- mixer model. The possibility to implement the solution in a wide range of existing RTP implementations made the RTP-mixer model be selected to be fully specified in this document. A capability exchange is specified so that it can be verified that a mixer and a participant can handle the multiparty-coded real-time text stream using the RTP-mixer method. The capability is indicated by use of an SDP media attribute "rtt-mixer". The document updates RFC 4103 "RTP Payload for Text Conversation". A specification of how a mixer can format text for the case when the endpoint is not multiparty-aware is also provided. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-avtcore-multi-party-rtt-mix-18.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-multi-party-rtt-mix-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 17 14:29:36 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6BF3A45A8; Mon, 17 May 2021 14:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mp2cZFEResz8; Mon, 17 May 2021 14:29:30 -0700 (PDT) Received: from smtp.egensajt.se (smtp.egensajt.se [193.42.159.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E9403A45A5; Mon, 17 May 2021 14:29:29 -0700 (PDT) Received: from [192.168.2.137] (h77-53-37-81.cust.a3fiber.se [77.53.37.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 47E9820199; Mon, 17 May 2021 23:29:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1621286968; bh=awlg9zBjERklLgOldYQ18MrSpaMu5V7ZDs4yk6A8dSo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=BglJ2cIiHl1XTG/onUe+sBV2t0fKXw8yHS05ST+SAqU8n5aUEm23R/y09RrLqWvaF 4hR7H2oJDJYw17BFe7QxBWfCmeZ7j74STh6Ql/+/ZSYjLwFGC15vZx8YSIBCber3P7 eW8OgNyGFNqXGccYVEAkPYiatUnjl/U5XAWDG2iQ= To: Martin Duke , The IESG Cc: avtcore-chairs@ietf.org, draft-ietf-avtcore-multi-party-rtt-mix@ietf.org, avt@ietf.org References: <162068222166.24279.17528511733896002331@ietfa.amsl.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <0d972786-1d24-5333-116c-ad17fd07c7e7@ghaccess.se> Date: Mon, 17 May 2021 23:29:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <162068222166.24279.17528511733896002331@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: sv Archived-At: Subject: Re: [AVTCORE] Martin Duke's No Objection on draft-ietf-avtcore-multi-party-rtt-mix-17: (with COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2021 21:29:35 -0000 The new version mentioned in a recent mail answering the comments by both Martin Duke and Lars Eggert is available. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-avtcore-multi-party-rtt-mix-18.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-multi-party-rtt-mix-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Regards Gunnar Den 2021-05-10 kl. 23:30, skrev Martin Duke via Datatracker: > Martin Duke has entered the following ballot position for > draft-ietf-avtcore-multi-party-rtt-mix-17: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > - It is not completely clear to me what the actions in the case of congestion > are. RFC 4103 RECOMMENDS four steps, the first is going from 300 to 500ms. So > what is the hiearchy here. My guess is: > > Step 1. Senders MUST go from 300ms to 2 seconds > Step 2. Senders SHOULD (further?) limit the number of characters sent > Step 3. Senders SHOULD go from 2 seconds to 5 seconds > Step 4. Senders SHOULD exclude nodes from the session > > Is this correct? > > - Assuming it is correct, I don't understand the motivation behind the > congestion considerations in Section 8. > > The first and third paragraphs make perfect sense to me. But if the total > traffic to a receiver, regardless of the number of senders, remains limited to > 1 packet / 300ms, I don't see why you would change the RFC 4103 guidance of > 500ms up to 2 seconds. This isn't a DISCUSS because you're welcome to be more > conservative, but I would like to understand your reasoning. > > No need to reply to the comments below: > > - In (3.16) and (4.2.2), you mention various privacy-sensitive fields and then > say "Integrity SHALL be considered..." I think you mean confidentiality? > Integrity means the data hasn't been altered by an attacker. > > - It would be helpful to clarify in this draft that the CPS limit applies only > to new, not redundant, text, assuming that is in fact the case. > > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt -- Gunnar Hellstrm GHAccess gunnar.hellstrom@ghaccess.se From nobody Tue May 18 07:35:54 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB613A14CF; Tue, 18 May 2021 07:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnVtIiNvu06G; Tue, 18 May 2021 07:35:44 -0700 (PDT) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2E603A14CE; Tue, 18 May 2021 07:35:43 -0700 (PDT) Received: by mail-il1-x12e.google.com with SMTP id c16so9358059ilo.1; Tue, 18 May 2021 07:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H++nekpn4zNj6xo5hkdkGPdl/IO4pBRJGkjldHwUgoI=; b=e7yTLkcM2hv6EZmmvl4aKZmktCkknNUbF3OQdafrke0rXHCzVqlOEp06ymJSiR3Rj+ KI5OnyB0J/neOk5xcvdHu5eQWWunv7xrbbe3Z+0YZ5B2S/NR8C9ErkCQvp4prJw19pCN 7ASsoID5Y8XCjGLaAd0PfRJsVxx5H5t5TqjWEv+gkeZVhoZFhV65HkI863Ib4aW92zAC AA0xg4VGa5FIP/dW9dtaAVIc7k+ardj/ykrrp9execPcW1/kk6lLn5yS378FU3Bpmikz 5W2GK2mroHcWEwZOyS+zkn3fxF4ghmSzuOTstjd6o8xtO2cNwDlJzZTZIF38Cpa16fIE YUUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H++nekpn4zNj6xo5hkdkGPdl/IO4pBRJGkjldHwUgoI=; b=W+oKnWThalitRsySANzr54UlIobkT61sGXLjxH8rKRZx9kyrLODVCQp2CVjta6va13 Vwx22iYVO8YVaambAWBsTgP6wuqeAXYssZvzHM9Cv7WGjx1v/S1EJuO5Zf6LgPEZ0Vwp +OUpk4XTEHEq8bENCyNIdaay2Q4Q7l8acsBp6oe6mRcsqm4VvzkKh/ECPPow51sH9hEp kzLa7QHK211mUghbroEg3P3if6wcKueXTd/b2ah2ycu5L04deceZ3ngEbPQc4uRthDK5 gHQThlgKFvBBcuBiquqaHsjvinpndNAChYVvIiCDBfw8DyzXLKbD4IAsbL+7gA4K4/hK 6hUQ== X-Gm-Message-State: AOAM533qDPfDTvqQTMZyAlbg8ZGR/y0H84hKKNw15uIOr3qgrJRvOdfP O/nyuLMhb0qC5HvWmBShWGjRCX4lnmF1looYCaK6fKfs9s0= X-Google-Smtp-Source: ABdhPJxhEBtVbWV6uFqFiS1HCbEH4EPW2VjNIv98FIdlk+p4b7GQ9yul4Sk+cHb17JS7UHTB/W5aaOFx8+mjgyrcya4= X-Received: by 2002:a05:6e02:218f:: with SMTP id j15mr4515962ila.249.1621348542121; Tue, 18 May 2021 07:35:42 -0700 (PDT) MIME-Version: 1.0 References: <162068222166.24279.17528511733896002331@ietfa.amsl.com> <0d972786-1d24-5333-116c-ad17fd07c7e7@ghaccess.se> In-Reply-To: <0d972786-1d24-5333-116c-ad17fd07c7e7@ghaccess.se> From: Martin Duke Date: Tue, 18 May 2021 07:35:37 -0700 Message-ID: To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= Cc: The IESG , avtcore-chairs@ietf.org, draft-ietf-avtcore-multi-party-rtt-mix@ietf.org, avt@ietf.org Content-Type: multipart/alternative; boundary="000000000000e90d0805c29b9f8a" Archived-At: Subject: Re: [AVTCORE] Martin Duke's No Objection on draft-ietf-avtcore-multi-party-rtt-mix-17: (with COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2021 14:35:49 -0000 --000000000000e90d0805c29b9f8a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable LGTM On Mon, May 17, 2021 at 2:29 PM Gunnar Hellstr=C3=B6m < gunnar.hellstrom@ghaccess.se> wrote: > The new version mentioned in a recent mail answering the comments by > both Martin Duke and Lars Eggert is available. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/ > > There is also an HTML version available at: > > https://www.ietf.org/archive/id/draft-ietf-avtcore-multi-party-rtt-mix-18= .html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-multi-party-rtt-mi= x-18 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Regards > Gunnar > > Den 2021-05-10 kl. 23:30, skrev Martin Duke via Datatracker: > > Martin Duke has entered the following ballot position for > > draft-ietf-avtcore-multi-party-rtt-mix-17: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix= / > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > - It is not completely clear to me what the actions in the case of > congestion > > are. RFC 4103 RECOMMENDS four steps, the first is going from 300 to > 500ms. So > > what is the hiearchy here. My guess is: > > > > Step 1. Senders MUST go from 300ms to 2 seconds > > Step 2. Senders SHOULD (further?) limit the number of characters sent > > Step 3. Senders SHOULD go from 2 seconds to 5 seconds > > Step 4. Senders SHOULD exclude nodes from the session > > > > Is this correct? > > > > - Assuming it is correct, I don't understand the motivation behind the > > congestion considerations in Section 8. > > > > The first and third paragraphs make perfect sense to me. But if the tot= al > > traffic to a receiver, regardless of the number of senders, remains > limited to > > 1 packet / 300ms, I don't see why you would change the RFC 4103 guidanc= e > of > > 500ms up to 2 seconds. This isn't a DISCUSS because you're welcome to b= e > more > > conservative, but I would like to understand your reasoning. > > > > No need to reply to the comments below: > > > > - In (3.16) and (4.2.2), you mention various privacy-sensitive fields > and then > > say "Integrity SHALL be considered..." I think you mean confidentiality= ? > > Integrity means the data hasn't been altered by an attacker. > > > > - It would be helpful to clarify in this draft that the CPS limit > applies only > > to new, not redundant, text, assuming that is in fact the case. > > > > > > > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > -- > Gunnar Hellstr=C3=B6m > GHAccess > gunnar.hellstrom@ghaccess.se > > --000000000000e90d0805c29b9f8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
LGTM

On Mon, May 17, 2021 at 2:29 PM Gunnar Hellstr=C3= =B6m <gunnar.hellstrom@g= haccess.se> wrote:
The new version mentioned in a recent mail answering the comment= s by
both Martin Duke and Lars Eggert is available.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org= /doc/draft-ietf-avtcore-multi-party-rtt-mix/

There is also an HTML version available at:
https://www.ietf.org/a= rchive/id/draft-ietf-avtcore-multi-party-rtt-mix-18.html

A diff from the previous version is available at:
https://www.ietf.org/rf= cdiff?url2=3Ddraft-ietf-avtcore-multi-party-rtt-mix-18


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Regards
Gunnar

Den 2021-05-10 kl. 23:30, skrev Martin Duke via Datatracker:
> Martin Duke has entered the following ballot position for
> draft-ietf-avtcore-multi-party-rtt-mix-17: No Objection
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.iet= f.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/
>
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> - It is not completely clear to me what the actions in the case of con= gestion
> are. RFC 4103 RECOMMENDS four steps, the first is going from 300 to 50= 0ms. So
> what is the hiearchy here. My guess is:
>
> Step 1. Senders MUST go from 300ms to 2 seconds
> Step 2. Senders SHOULD (further?) limit the number of characters sent<= br> > Step 3. Senders SHOULD go from 2 seconds to 5 seconds
> Step 4. Senders SHOULD exclude nodes from the session
>
> Is this correct?
>
> - Assuming it is correct, I don't understand the motivation behind= the
> congestion considerations in Section 8.
>
> The first and third paragraphs make perfect sense to me. But if the to= tal
> traffic to a receiver, regardless of the number of senders, remains li= mited to
> 1 packet / 300ms, I don't see why you would change the RFC 4103 gu= idance of
> 500ms up to 2 seconds. This isn't a DISCUSS because you're wel= come to be more
> conservative, but I would like to understand your reasoning.
>
> No need to reply to the comments below:
>
> - In (3.16) and (4.2.2), you mention various privacy-sensitive fields = and then
> say "Integrity SHALL be considered..." I think you mean conf= identiality?
> Integrity means the data hasn't been altered by an attacker.
>
> - It would be helpful to clarify in this draft that the CPS limit appl= ies only
> to new, not redundant, text, assuming that is in fact the case.
>
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt

--
Gunnar Hellstr=C3=B6m
GHAccess
gunnar.he= llstrom@ghaccess.se

--000000000000e90d0805c29b9f8a-- From nobody Tue May 18 13:34:43 2021 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A733A0A6F; Tue, 18 May 2021 13:34:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Francesca Palombini via Datatracker To: "The IESG" Cc: draft-ietf-avtcore-multi-party-rtt-mix@ietf.org, avtcore-chairs@ietf.org, avt@ietf.org, bernard.aboba@gmail.com, bernard.aboba@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.29.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Francesca Palombini Message-ID: <162137008198.8563.14104995910062091869@ietfa.amsl.com> Date: Tue, 18 May 2021 13:34:41 -0700 Archived-At: Subject: [AVTCORE] Francesca Palombini's No Objection on draft-ietf-avtcore-multi-party-rtt-mix-18: (with COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2021 20:34:42 -0000 Francesca Palombini has entered the following ballot position for draft-ietf-avtcore-multi-party-rtt-mix-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work on this document. I have some minor non-blocking comments (feel free to take them or leave them), but I'd like some response to point 6. about the normative MUST. Francesca 1. ----- FP: Please expand acronyms (CSRC, SDP, BOM, PSTN,...) on first use. 2. ----- Since simultaneous typing by more than two parties is very rare, this method can be used successfully with good performance. Recovery FP: I had question on this point, i.e. how was it evaluated that simultaneous typing by more than two parties is very rare, but that was answered in section 1.3 Intended application - so I would suggest adding a forward reference to that section in the paragraph quoted above. 3. ----- text stream using the RTP-mixer method. The capability is indicated by use of an SDP media attribute "rtt-mixer". FP: Please add a reference to RFC 8866. 4. ----- streams in text format. This is especially true if support of un- encrypted SIP and media is supported because of lack of such support in the target endpoints. However, the mixing for conference-aware FP: I have a problem parsing this sentence "... if support ... is supported because of lack of such support" 5. ----- is the timestamp of packet 102 THAT was received. So B1 does not FP: nit - all capitals THAT. 6. ----- the stream. Some of them are optional. Implementations MUST be able to ignore optional control codes that they do not support. FP: I am really unsure how this MUST can be verified for interoperability. Maybe this does not need to be a BCP 14 MUST? 7. ----- | | | |(mix)[Bob)] Bob as well. | | FP: one space character too much From nobody Tue May 18 14:42:54 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73E73A104E; Tue, 18 May 2021 14:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhH3Uuwk4CuC; Tue, 18 May 2021 14:42:47 -0700 (PDT) Received: from smtp.egensajt.se (smtp.egensajt.se [194.68.80.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71E2B3A104D; Tue, 18 May 2021 14:42:47 -0700 (PDT) Received: from [192.168.2.137] (h77-53-37-81.cust.a3fiber.se [77.53.37.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 33DD320CB9; Tue, 18 May 2021 23:42:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1621374164; bh=pP8rkkKMXH6vcu1fpXZriu38jrk2cDmarIy7lliId2c=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=rRucE468RrOc3HNr96fFiZn8shz4qcVwOSBCVHInm4kzrSHftOZBBYCDUfSKnJ6NN eKUXvJubmsYosOCqfnE7Uo8W39GJI6dUVxHGv3JgcsLOGeBhcPT2zmGN6ra73jyZmS p/Cmt72anhsJ6pKwCUsG4h/PO2IQ1icDcOL0+qLQ= To: Francesca Palombini , The IESG Cc: avtcore-chairs@ietf.org, draft-ietf-avtcore-multi-party-rtt-mix@ietf.org, avt@ietf.org References: <162137008198.8563.14104995910062091869@ietfa.amsl.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Tue, 18 May 2021 23:42:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <162137008198.8563.14104995910062091869@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: sv Archived-At: Subject: Re: [AVTCORE] Francesca Palombini's No Objection on draft-ietf-avtcore-multi-party-rtt-mix-18: (with COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2021 21:42:53 -0000 Francesca, thank you for your review. I will answer your question 6 here, and follow up soon with a new version with actions on all comments. Den 2021-05-18 kl. 22:34, skrev Francesca Palombini via Datatracker: > Francesca Palombini has entered the following ballot position for > draft-ietf-avtcore-multi-party-rtt-mix-18: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the work on this document. I have some minor non-blocking > comments (feel free to take them or leave them), but I'd like some response to > point 6. about the normative MUST. > > Francesca .... > 6. ----- > > the stream. Some of them are optional. Implementations MUST be able > to ignore optional control codes that they do not support. > > FP: I am really unsure how this MUST can be verified for interoperability. > Maybe this does not need to be a BCP 14 MUST? Yes, this MUST is intended to be a normative MUST. And it is very important but not that complicated to properly ignore unsupported control codes. The control codes are specified in ITU-T T.140, in turn referencing to ISO 6429. The control codes often consist of a special leading character, followed by a parameter consisting of normal text characters, and then a final special character. Ignoring an unsupported control code means that the app needs to understand the structure of control codes, so that it ignores everything from the leading special character to and including the final special character. It would be incorrect and cause garbage in the display or even malfunction if it just ignored the leading special character and then interpreted the characters in the parameter as if it was text and tried to present it. The control codes can imply change in color or blinking or other visible effects in the text, and it is said that such effects are optional. Would more explaining text be required for this section? Regards Gunnar > > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt -- Gunnar Hellstrm GHAccess gunnar.hellstrom@ghaccess.se From nobody Tue May 18 19:27:34 2021 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3493A19AC; Tue, 18 May 2021 19:27:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-avtcore-multi-party-rtt-mix@ietf.org, avtcore-chairs@ietf.org, avt@ietf.org, bernard.aboba@gmail.com, bernard.aboba@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.29.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <162139124891.22846.16818872777832269848@ietfa.amsl.com> Date: Tue, 18 May 2021 19:27:29 -0700 Archived-At: Subject: [AVTCORE] Roman Danyliw's No Objection on draft-ietf-avtcore-multi-party-rtt-mix-18: (with COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2021 02:27:30 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-avtcore-multi-party-rtt-mix-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Rich Salz for the SECDIR review. ** Section 11. Per “Participants with malicious intentions may appear ...”, this text seems to be describing an attacker that is party to the call. If the mitigations suggested in the next sentence (i.e., secure signaling ... and authentication) aren’t present, this style of attack may also be possible by an on-path attacker as might be simple eavesdropping or injection of arbitrary content. ** Section 11. Would the caution of the mixer not revealing that a user is hearing or speech impaired noted in Section 8 of RFC5194 apply here too? From nobody Tue May 18 19:53:21 2021 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC613A1A8E; Tue, 18 May 2021 19:53:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-avtcore-multi-party-rtt-mix@ietf.org, avtcore-chairs@ietf.org, avt@ietf.org, bernard.aboba@gmail.com, bernard.aboba@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.29.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <162139279927.706.12647899386073526674@ietfa.amsl.com> Date: Tue, 18 May 2021 19:53:19 -0700 Archived-At: Subject: [AVTCORE] Benjamin Kaduk's Discuss on draft-ietf-avtcore-multi-party-rtt-mix-18: (with DISCUSS and COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2021 02:53:20 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-avtcore-multi-party-rtt-mix-18: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'm not sure I understand how the examples are consistent with the main specification, so let's please discuss it to either un-confuse me or fix the document. Section 3.9 seems to say that the oldest (source or redundant) text at the mixer takes priority when there is text from more than one source waiting to be sent, but the examples in Section 3.21 seem to show (e.g.) text received from A at time 20400 that is to be sent as redundancy, being sent after text from B received at time 20500 (sent as primary). Is the intent that if there is any primary text, the oldest primary text is sent first, and only if there is no outstanding primary text do we consider the redundant text? In a related vein, Section 3.10 says that a packet is sent when (among other things) "330 ms has passed since already transmitted text was queued for transmission as redundant text". But that doesn't say anything about the timer being reset by subsequent transmission or queuing of redundant text, so I'm not sure how in the Section 3.21 example, we say that transmitting B1 and B2 as redundancy was planned as 330 ms after packet 105 -- the original B2 was sent in packet 104, so shouldn't the 330ms start from packet 104's transmission? (The stated time for this seems to match 330ms after 104, so maybe the "105" is just a typo?) I also left a note in the comment that there's a remark about "lower security level" in Section 3.19 that's not really accurate; we should resolve that in some manner before the document proceeds. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The abstract is perhaps pushing the boundary of length reasonable for an abstract. There were a couple interesting remarks in the shepherd writeup: % The specification has not been implemented yet, so it is possible that % issues could arise in implementation. This is more of a concern than % for typical AVTCORE documents, since this specification is likely to % become a regulatory requirement prior to advancing beyond Proposed % Standard. Are there still no implementations? Are we happy with publishign the specification at this time in the absence of implementations? % During review, the question was raised as to whether the specification % will require development of an RTT mixer, or whether it could be made % compatible with existing conferencing servers implementing Selective % Forwarding. What was the outcome of the discussion? Should that be reflected in the document? Abstract mixer model. The possibility to implement the solution in a wide range of existing RTP implementations made the RTP-mixer model be selected to be fully specified in this document. It's a little surprising to see this claim given the absence (per the shepherd writeup) of any actual implementations. Section 1.2 Multiple sources per packet A new "text" media subtype would be specified with up to 15 sources in each packet. The mechanism would make use of the RTP mixer model specified in RTP [RFC3550]. Text from up to 15 sources can be included in each packet. [...] (How was the "15" number determined?) Section 2.3.2 A party receiving an offer containing the "rtt-mixer" SDP attribute and being willing to use the RTP-mixer-based method of this specification for sending or receiving or both sending and receiving SHALL include the "rtt-mixer" SDP attribute in the corresponding "text" media section in the answer. This requirement doesn't quite seem to match up with what I expect -- an answerer that's willing to use rtt-mixer and also willing to use something else seems to still be bound by the "SHALL include" in the first paragraph, which makes the willingness to use something else a bit irrelevant and precludes choosing the other option. Perhaps we want to say only "chooses to use the RTP-mixer-based method of this specification"? Section 3.2 What purpose does the initial BOM serve? I note that, e.g., RFC 5198 has an explicit BOM "MUST NOT appear at the beginning of these text strings" and that RFC 4103 specifies UTF-8 encoding of the text. I see in Section 3.17.4 (and 4.2.1) we mention that it might be used for keepalive, but in rtt-mix don't we have lots of non-BOM keepalive options? Section 3.4 If the "CPS" value is reached, longer transmission intervals SHALL be applied and only as much of the text queued for transmission SHALL be sent at the end of each transmission interval that can be allowed without exceeding the "CPS" value, until the transmission rate falls under the "CPS" value again. [...] This doesn't seem as precisely specified as it could be, given that the CPS rate is supposed to be enforced over "any 10-second interval". As written, this seems to suggest that the entire 10-second history of packet size/spacing needs to be retained, so that at each transmission the earliest time for next transmission can be computed that retains the CPS limit. It's not clear that there's real need for such a complicated solution vs something that more bluntly backs off the transmit rate and uses bucketed averages for tracking the transmission rate. (I have no idea why it's 330ms for a mixer and 300ms for a non-mixer, but assume there is some reason for the difference.) Section 3.6 Text received by a mixer from a participant SHOULD NOT be included in transmission from the mixer to that participant, because the normal behavior of the endpoint is to present locally-produced text locally. When would the SHOULD NOT be ignored? (How might a mixer know that the other endpoint is not using the "normal behavior" of presenting locally-produced text locally?) Section 3.7 A mixer SHALL handle reception, recovery from packet loss, deletion of superfluous redundancy, marking of possible text loss and deletion of 'BOM' characters from each participant before queueing received text for transmission to receiving participants. Are there specific references available for each of these operations? Section 3.9 The source with the oldest text received in the mixer or oldest redundant text SHALL be next in turn to get all its available unsent text transmitted. Any redundant repetitions of earlier transmitted Just to confirm: this is really *all* its available unsent text, not just however much will fit in one packet/flight/etc.? Can a participant "hog the mic" by continuing to append to that list even as transmission has commenced? Section 3.13 It took me a bit of searching to realize that it is RFC 2198 that specifies the additional header that includes the "timestamp offset" field. A specific reference here (or maybe from an earlier section?) would have helped me out. Section 3.14 The SSRC of the mixer for the RTT session SHALL be inserted in the SSRC field of the RTP header. As written, this could be taken to say that the non-mixer endpoint should also use the SSRC of the mixer. Section 3.16 Confidentiality SHALL be considered when composing these fields. I think "privacy considerations" would be more relevant than "confidentiality". Similar considerations SHALL be taken as for other media. This seems rather vague and it's not really clear how the implementor is supposed to take action based on it. (Note that media are typically straight over (S)RTP, but these reports are (S)RTCP, which admittedly is also over (S)RTP, but is still different.) Section 3.17.2 If it is known that only one source is active in the RTP session, then it is likely that a gap equal to or larger than the agreed number of redundancy generations (including the primary) causes text loss. [...] Some more care in description may be needed here, as the gap in RTP sequence numbers is measured in the RTP sequence units (e.g., time), but the redundancy generation number is just a dimensionless generation count. We need to assume the max inter-packet spacing in order to convert that into a time value that is suitable for assuming loss. evaluate if three or more packets were lost within one second. If this simple method is used, then a t140block SHOULD be created with a marker for possible text loss [T140ad1] and associated with the SSRC of the transmitter as a general input from the mixer. Does "input from the mixer" mean that it uses the mixer's SSRC value? Or is this injected by the mixer (in contrast to the previous paragraph, where it was the receiver that injects the marker for possible text loss)? Section 3.17.3 If the packet is not the first packet from a source, then if the second generation redundant data is available, its timestamp SHALL be created by subtracting its timestamp offset from the RTP timestamp. If the resulting timestamp is later than the latest retrieved data from the same source, then the redundant data SHALL be retrieved and appended to the receive buffer. The process SHALL be continued in the same way for the first generation redundant data. After that, the primary data SHALL be retrieved from the packet and appended to the receive buffer for the source. I think I can come up with reordering scenarios that cause this procedure to discard data that would otherwise have recovered from loss. Also, this procedure as written says that the primary data shall always be appended to the receive buffer (with no time check), which could result in doubled content in the case of reordering. Section 3.19 Security SHOULD be applied when possible regarding the capabilities of the participating devices by use of SIP over TLS by default "Security" is not some all-encompassing attribute that can be generically applied; there are specific security properties that may or may not be achieved by any given mechanism, and it's generally worth being precise about what properties are (or are not) achieved. So here we might say "security mechanisms to provide confidentiality and integrity protection and peer authentication SHOULD be applied". We cannot in general achieve source authenticity with just SRTP when a mixer is involved, though RFC 8723 does specify a double-encryption mechanism that applies in some cases when there is a central media distributor. In applications where legacy endpoints without security may exist, a negotiation SHOULD be performed to decide if encryption on the media level will be applied. [...] How would endpoints know if legacy endpoints might exist? How would this negotiation be performed? security levels. The mixing for conference-unaware endpoints has lower security level than the mixing method for conference-aware endpoints, because there may be an opportunity for a malicious mixer or a middleman to masquerade the source labels accompanying the text streams in text format. This is especially true if support of un- encrypted SIP and media is supported because of lack of such support in the target endpoints. However, the mixing for conference-aware endpoints as specified here also requires that the mixer can be trusted. [...] As the last sentence indicates, the provided reasoning in the first sentence is not really accurate, since the mixer could just as easily adjust the CSRC value in the header as change the label in the in-band text stream. This does not inherently invalidate the claim that there are different security levels, though, as the correct behavior of the mixer seems easier to independently validate in the conference-aware endpoint case (with the well-formed RTP payloads providing information that can be validated out-of-band with other participants). But I don't think this description should be left in the document as-is; it doesn't seem accurate. In the case of unencrypted media, it does seem technically true that it is easier for a non-mixer middleman to masquerade the source labels, since in that case it only adjusts the payload directly without needing to keep state on the RTP sender information and produce well-formed RTP headers after its adjustment. But this is only a modest level of additional difficulty and does not reflect any kind of effective security control, so it may not be worth mentioning at all. End-to-end encryption would require further work and could be based on WebRTC as specified in Section 1.2. Is RFC 8723 not applicable to these scenarios at all? I do not think it is WebRTC-specific. Section 3.21 Transmission of A2 and A3 as redundancy is planned for 330 ms after packet 101 if no new text from A is ready to be sent before that. I thought new text from *anyone* would trigger sending A2 and A3 as redundancy, per §3.9. Is there any reason why the dummy offsets in 104 are 300/600 but the dummy offsets in 103 are 330/660? Section 4.2 In order to expedite source switching, a user can, for example, end its turn with a new line. How would a user know that there is a legacy endpoint in the coversation so as to choose to end its turn in this way? Section 4.2.2 * A long pause (e.g., > 10 seconds) in received text from the currently transmitted source * If text from one participant has been transmitted with text from other sources waiting for transmission for a long time (e.g., > 1 minute) and none of the other suitable points for switching has I think I'm confused how we could hit the 1 minute timer before the 10 seconds timer has triggered. Section 11 I think that the obvious attacks involving control characters are addressed in one way or another, but it might be worth a reminder to implementors that control characters should not be allowed to let one user's content affect the display of other users' content, or the presentation-format's label of the sender, etc. It might be appropriate to have yet another reminder here that SRTP is the recommended mode of operation. The requirement to transfer information about the user in RTCP reports in SDES, CNAME, and NAME fields, and in conference notifications, for creation of labels may have privacy concerns as already stated in RFC 3550 [RFC3550], [...] Could you point me to where this is stated in RFC 3550? I looked in the security considerations (section 14) and searched for all instances of "CNAME", but didn't see discussion about SDES/CNAME/NAME being privacy sensitive. Section 13.1 RFC 8825 is not currently referenced in any context that specifically requires it to be listed as a normative reference. This may suggest that it should be referenced in more places (e.g., in the discussion of gateway considerations with WebRTC). NITS Section 1 Use of RTT is increasing, and specifically, use in emergency calls is increasing. Emergency call use requires multiparty mixing. [...] I expect the conclusion that emergency-call use requires mixing to be non-intuitive to many readers, so additional explanation might be helpful. RFC 4103 "RTP Payload for Text Conversation" mixer implementations can use traditional RTP functions for source identification, but the The word "mixer" (or even "mix") does not appear in RFC 4103, so I'm not sure how to interpret "RFC 4103 mixer implementations". Perhaps it is an RFC 3550 mixer acting on RFC 4103 payloads? The document updates [RFC4103] by introducing an attribute for indicating capability for the RTP-mixer-based multiparty mixing case and rules for source indications and interleaving of text from different sources. I think "indicating capability for the RTP-mixer-based multiparty mixing case" needs another verb. Section 2.2 A party acting as a mixer, which has not negotiated any method for true multiparty RTT handling, but negotiated a "text/red" or "text/ t140" format in a session with a participant SHOULD in order to maintain interoperability, if nothing else is specified for the application, format transmitted text to that participant to be suitable to present on a multiparty-unaware endpoint as further specified in Section 4.2. comma after "SHOULD". The whole sentence is a bit long, though, and the parenthetical "if nothing else is specified for the application" is somewhat in the way in its current location. Further reworking may be in order. I'd also consider s/format transmitted text/transmit formatted text/ or /format text transmitted/. Section 2.3.4 If the modified offer deletes indication of support for multiparty real-time text by excluding the "rtt-mixer" SDP attribute, the answer MUST NOT contain the "rtt-mixer" attribute, and both parties SHALL after processing the SDP exchange NOT send real-time text formatted for multiparty-aware parties according to this specification. The BCP 14 keyword "SHALL NOT" is supposed to appear as the specific phrase, so something like "SHALL NOT, after processing the SDP exchange, send" seems more appropriate. Section 3.4 transmission MUST then be made at T140block borders. See also Section 8 full stop at end of sentence. Section 3.10 The mixer SHALL compose and transmit an RTP packet to a receiver when one of the following conditions has occurred: Maybe "one or more" (or "one or both")? Section 3.16 Confidentiality SHALL be considered when composing these fields. They contain name and address information that may be sensitive to transmit in its entirety e.g., to unauthenticated participants. comma before "e.g." (as well as after) Section 3.17 presentation areas for each source. Other receiver roles, such as gateways or chained mixers are also feasible, and requires consideration if the stream shall just be forwarded, or distributed "such as gateways or chained mixers" seems like a parenthetical phrase that should be offset by commas on both sides. Also, "require consideration" seems to match up better with the plural "roles". Section 3.17.3 When a packet is received in an RTP session using the packetization for multiparty-aware endpoints, its T140blocks SHALL be extracted in the following way. The description is adapted to the default redundancy case using the original and two redundant generations. Is this supposed to imply that the extension to the generic case with other levels of redundancy is trivial for the reader to perform? Section 3.18 This solution has good performance with low text delays as long as the sum of characters per second during any 10-second interval sent from a number of simultaneously sending participants to a receiving participant does not reach the 'CPS' value. [...] "sum of characters per second during any 10-second interval" seems to mean "compute CPS for each second, then add them up". I don't think that's the intended meaning. Only in large unmanaged conferences with a high number of participants there may on very rare occasions appear situations when many participants happen to send text simultaneously, resulting in unpleasantly jerky presentation of text from each sending participant. [...] This sentence seems a bit long and winding. Section 3.20 Offer example for "text/red" format including multiparty and security: a=fingerprint: (fingerprint1) I think it would be preferred to make up some random fingerprints and use them instead of the placeholder string (throughout). Section 3.21 offset 660 ms. The timestamp of packet 106 minus 660 is 20500 which is the timestamp of packet 102 THAT was received. So B1 does not I don't see why "THAT" needs to be in all majuscule letters. Section 3.22 to transmission to a receiver. The value MAY be modified in the "CPS" parameter of the FMTP attribute in the media section for the "text/t140" media. [...] RFC 4103 seems to show the lowercase "cps" parameter name (there are subsequent occurrences that I do not quote). Section 4.2 one presentation area. The mixer SHALL group text in suitable groups and prepare for presentation of them by inserting a new line between them if the transmitted text did not already end with a new line. A Is "new line" specified somewhere? Up in toplevel §4 we cover the unicode line separator and CRLF sequences but don't use the phrase "new line". Section 4.2.2 Information available to the mixer for composing the label may contain sensitive personal information that SHOULD not be revealed in "SHOULD NOT" in all caps sessions not securely authenticated and protected. Integrity "confidentiality protected" considerations regarding how much personal information is included in the label SHOULD therefore be taken when composing the label. I don't think "integrity" is the right word here. Section 11 Therefore, the mixer needs to be trusted to achieve security in confidentiality and integrity. [...] s/trusted to achieve security in confidentiality and integrity/trusted to maintain confidentiality and integrity of the RTT data/ The requirement to transfer information about the user in RTCP reports in SDES, CNAME, and NAME fields, and in conference notifications, for creation of labels may have privacy concerns as There's something awry with the commas around "for creation of labels". From nobody Wed May 19 06:48:42 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8EF3A1053; Wed, 19 May 2021 06:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNOHV6B9xedq; Wed, 19 May 2021 06:48:34 -0700 (PDT) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A1873A1052; Wed, 19 May 2021 06:48:34 -0700 (PDT) Received: by mail-yb1-xb2c.google.com with SMTP id i4so18201207ybe.2; Wed, 19 May 2021 06:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V6nzDgff2FWh/KvWvFqdJ22mFfrBITHuNChfPMuTq3s=; b=RwJfToZozZYQ6cp8jqNTyQ8UuwNBgYt4ZOWrTxWWA3UBDmuJ25+gbjYQSp9jQ4kzAG YH8N1InJkOsh8UQy/0mH+EzXBQb702n3xpgHn2+U8KsTb7RzcTIWYfCYUvcWZGio6xPQ 8/CB8qR9lubNzSaX64awLGr6Yo7LymsnduaDiuJ0HIqbItCoNESJ48nHaxJwdtdZ5Bk7 /VoDZbPtcNcQfHnspMlAUa9GWQyMazmbYsXNx4QIvYCJI2Y/UHwlH1N7inm9cgPRPp6R fRTQok4PAkX2OEZe5e5QPxM4bPS6MAaqkUaElam3sPWmNxuqNOZvtfz2CM0xPGFoo2qv +cnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V6nzDgff2FWh/KvWvFqdJ22mFfrBITHuNChfPMuTq3s=; b=FG9cJwsCV7BqFaAoaRLkwZOX9Q4t1ecv+pxSced4QQ2b7yds9hh06cPw64oJjwtWsx u3jxCgdZLi2zrbK1/G/oVHzUKyz87pxULPN10neb2qagX2N5sB1zbm4XYlvdWhWF4pkw fscN77RdxIjbm5caGDarSQKyj8ctZ4eDReYHQ49I2M7xves4tq0m+hfMNonxhNQVGZtM No5h2+FgLQ8r2bEvm5Iy5+DsGbsgwpUpRI/+uUM9FiGfoonSzElHX8CF7I5uVb0MsSA0 qYJUX7GSvXqUP/xd1gLkFPUy1wkz8sxJnS+UP4IW4nB3T4NsNt2jlbtjUvR0TJZNxZX8 srJg== X-Gm-Message-State: AOAM533fGG9D7F/vOrKhQRumt2B8GXVGY2zQRu12ZuR0hqvbDuqZin9P 9AfiPHz/Gxo+EaXqjv9BAwkkFiPCVNVJ4eP3gtA= X-Google-Smtp-Source: ABdhPJwtrkzOOTm46BZXmLNXOyESBChsAa3Ax7PP8+aM3PqN83m6rOwNumR5ACAZz2tGdA9eNGPIrqy4ZgQxzocJua8= X-Received: by 2002:a5b:f50:: with SMTP id y16mr16373608ybr.297.1621432112293; Wed, 19 May 2021 06:48:32 -0700 (PDT) MIME-Version: 1.0 References: <162137008198.8563.14104995910062091869@ietfa.amsl.com> In-Reply-To: From: Spencer Dawkins at IETF Date: Wed, 19 May 2021 08:48:06 -0500 Message-ID: To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= Cc: Francesca Palombini , The IESG , avtcore-chairs@ietf.org, draft-ietf-avtcore-multi-party-rtt-mix@ietf.org, IETF AVTCore WG Content-Type: multipart/alternative; boundary="00000000000014aa7c05c2af15c6" Archived-At: Subject: Re: [AVTCORE] Francesca Palombini's No Objection on draft-ietf-avtcore-multi-party-rtt-mix-18: (with COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2021 13:48:40 -0000 --00000000000014aa7c05c2af15c6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I apologize for asking, but ... On Tue, May 18, 2021 at 4:43 PM Gunnar Hellstr=C3=B6m < gunnar.hellstrom@ghaccess.se> wrote: > Francesca, > > thank you for your review. I will answer your question 6 here, and > follow up soon with a new version with actions on all comments. > > Den 2021-05-18 kl. 22:34, skrev Francesca Palombini via Datatracker: > > Francesca Palombini has entered the following ballot position for > > draft-ietf-avtcore-multi-party-rtt-mix-18: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix= / > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thank you for the work on this document. I have some minor non-blocking > > comments (feel free to take them or leave them), but I'd like some > response to > > point 6. about the normative MUST. > > > > Francesca > .... > > 6. ----- > > > > the stream. Some of them are optional. Implementations MUST be ab= le > > to ignore optional control codes that they do not support. > > > > FP: I am really unsure how this MUST can be verified for > interoperability. > > Maybe this does not need to be a BCP 14 MUST? > Gunnar, When I read your response to Francesca's comment, my next question was whether an implementation should always ignore optional control codes that they do not support, if *not* ignoring them just cause problems, displays garbage characters, etc. If that's correct, I'm not Francesca, of course, but I'd think "Implementations MUST ignore optional control codes that they do not support" would be verifiable for interoperability, and would justify a BCP 14 MUST.. Best, Spencer > Yes, this MUST is intended to be a normative MUST. And it is very > important but not that complicated to properly ignore unsupported > control codes. > > The control codes are specified in ITU-T T.140, in turn referencing to > ISO 6429. The control codes often consist of a special leading > character, followed by a parameter consisting of normal text characters, > and then a final special character. > > Ignoring an unsupported control code means that the app needs to > understand the structure of control codes, so that it ignores everything > from the leading special character to and including the final special > character. > > It would be incorrect and cause garbage in the display or even > malfunction if it just ignored the leading special character and then > interpreted the characters in the parameter as if it was text and tried > to present it. > > The control codes can imply change in color or blinking or other visible > effects in the text, and it is said that such effects are optional. > > > Would more explaining text be required for this section? > > > Regards > > Gunnar > > > > > > > > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > -- > Gunnar Hellstr=C3=B6m > GHAccess > gunnar.hellstrom@ghaccess.se > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --00000000000014aa7c05c2af15c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I apologize for asking, but ...=C2=A0

On Tue, May 18, = 2021 at 4:43 PM Gunnar Hellstr=C3=B6m <gunnar.hellstrom@ghaccess.se> wrote:
Francesca,

thank you for your review. I will answer your question 6 here, and
follow up soon with a new version with actions on all comments.

Den 2021-05-18 kl. 22:34, skrev Francesca Palombini via Datatracker:
> Francesca Palombini has entered the following ballot position for
> draft-ietf-avtcore-multi-party-rtt-mix-18: No Objection
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.iet= f.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/
>
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> Thank you for the work on this document. I have some minor non-blockin= g
> comments (feel free to take them or leave them), but I'd like some= response to
> point 6. about the normative MUST.
>
> Francesca
....
> 6. -----
>
>=C2=A0 =C2=A0 =C2=A0the stream.=C2=A0 Some of them are optional.=C2=A0 = Implementations MUST be able
>=C2=A0 =C2=A0 =C2=A0to ignore optional control codes that they do not s= upport.
>
> FP: I am really unsure how this MUST can be verified for interoperabil= ity.
> Maybe this does not need to be a BCP 14 MUST?
Gunnar,=C2=A0

When I read your respons= e to Francesca's comment, my next question was whether an implementatio= n should always ignore optional control codes that they do not support, if = *not* ignoring them just cause problems, displays garbage characters, etc.= =C2=A0

If that's correct, I'm not Francesc= a, of course, but I'd think "Implementations MUST ignore optional = control codes that they do not support" would be verifiable for intero= perability, and would justify a BCP 14 MUST..=C2=A0

Best,

Spencer
=C2=A0
Yes, this MUST is intended to be a no= rmative MUST. And it is very
important but not that complicated to properly ignore unsupported
control codes.

The control codes are specified in ITU-T T.140, in turn referencing to
ISO 6429. The control codes often consist of a special leading
character, followed by a parameter consisting of normal text characters, and then a final special character.

Ignoring an unsupported control code means that the app needs to
understand the structure of control codes, so that it ignores everything from the leading special character to and including the final special
character.

It would be incorrect and cause garbage in the display or even
malfunction if it just ignored the leading special character and then
interpreted the characters in the parameter as if it was text and tried to present it.

The control codes can imply change in color or blinking or other visible effects in the text, and it is said that such effects are optional.


Would more explaining text be required for this section?


Regards

Gunnar

>
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt

--
Gunnar Hellstr=C3=B6m
GHAccess
gunnar.he= llstrom@ghaccess.se

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt
--00000000000014aa7c05c2af15c6-- From nobody Wed May 19 06:58:39 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBA93A10B3; Wed, 19 May 2021 06:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkNQPw1YGbfd; Wed, 19 May 2021 06:58:28 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2072.outbound.protection.outlook.com [40.107.22.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC6C83A10B0; Wed, 19 May 2021 06:58:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RT4QcgZufpHDDgLquLbv6XfpCSdo+7OlBBZ8s/OG0X8c7/S+J9aNhA/PQC8hf0kYQG9QgMaXHrt6JVPUMaRB+fUI6iaE0nyvQs2Pb3SUynqjmPSOdrBFe5e/lWM+XU5BmqYVZhDyOVDMHuF0gC8Tggei+muaYvf5q4R8ATQ/oJozMU/9mQ510SOXDUp2H/4Rre5WtZTIwzDbyQH7OW9jaByEHpNs/CByUE0a7wjTSxPTbJe2AU6uPqyCeFzpkjgd8/5p0nAHUt3K+l+DlCxq5H2hHP5TXjEP6FjyiHXU5VCVoeCcJrwv3NKT94B4mUQRfseJGTcP8T+tcxJtehsZ9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WQvVpecPXqYfwaoygc9/XNpRGJ2FY3h6+KBr7jD+kss=; b=oV5s0kMl3YF3dqRW9pVQ0Pfb3cg6wNcL5x907jAuNS4LfO58BmmQinEJ3E9HA4yB/5P3FlzPO5GgR4qypDMEkvV+Ss+KB4VN7reegubVHyd+6liLElMaEJKVEgFmEukaIuxkOpSKYwZymIF/SKaDpW+GV9/I2vcAkuvZig3xiZZFjh3aRUnD2rbC+HXTEm4xJO5Q0VoQI8KFz+nryQRcx3MUdOBRl3ONWFxUUOZlzxQAcOhNBbvsENKEDcUapoMZi2VC6cwPgdY1D+2Q08rbw4OKjLIJeWnMbBhQ42xMKsg4W+mWXNaWSqXKQ2aK544OMjDlF9ch+XBrUTvIXKphaQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WQvVpecPXqYfwaoygc9/XNpRGJ2FY3h6+KBr7jD+kss=; b=FIc4gnQz+pF1FXqsoGD/ZPWg8hzFsQUG9xB7/MjxcbKsPzYYiVsnZLzkadVtqIIVMXujd3qGdRD0QkTeIRIpc6fqdHlo0GFEGyl99eSOLc0Q8hpvSam4o5mzWclv8J42SNcdhPfFFwy/9hKkfo9Dd0R+AgsdoZj/MlA8vr0KmpE= Received: from HE1PR07MB4217.eurprd07.prod.outlook.com (2603:10a6:7:96::33) by HE1PR0701MB2459.eurprd07.prod.outlook.com (2603:10a6:3:72::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.14; Wed, 19 May 2021 13:58:22 +0000 Received: from HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::f4cb:88d1:88fc:d707]) by HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::f4cb:88d1:88fc:d707%6]) with mapi id 15.20.4150.017; Wed, 19 May 2021 13:58:22 +0000 From: Francesca Palombini To: Spencer Dawkins at IETF , =?utf-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= CC: The IESG , "avtcore-chairs@ietf.org" , "draft-ietf-avtcore-multi-party-rtt-mix@ietf.org" , IETF AVTCore WG Thread-Topic: [AVTCORE] Francesca Palombini's No Objection on draft-ietf-avtcore-multi-party-rtt-mix-18: (with COMMENT) Thread-Index: AQHXTCVHB2zPtVcNXE2pt8ImDTgaYqrpxSsAgAENuwCAACRkgA== Date: Wed, 19 May 2021 13:58:22 +0000 Message-ID: References: <162137008198.8563.14104995910062091869@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.49.21050901 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:1ba8:147a:eb00:28f6:2106:d2b3:6d3e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2c955005-8181-4e43-17b4-08d91ace2a44 x-ms-traffictypediagnostic: HE1PR0701MB2459: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LwoPoIHIKqbyUqVOyxc8EhxxrfW3+50NIUYym87roiN5WVV9/dxDlpSMtUOjb+BkltsNx7MNUqhHhFBtzx/IFmpowrT/Ay0K3FdZdgWVgHvzkDxihXJ+P+oVxupsdjoRsDBLPSIl3sS+cGonjA0d9vejLc7/uiumoGZZ2xMiAhaXDuhRBmKlSStn4a4RvLqM2/m3v3aOROp0gyaXyZ0jaTL+GsMSYw7WpboVQucPLMM5aikFJ9LK4kAo8BTS5bTc3r/xgYe3s1Ko4tK3abQZdqOVZ7iC6r4UCosawkohArWySs/Gw4EXJH51cLj77dEY/z7LFCuX2ZJ87b/Sa/9PSX45U/LGI7Q8A0CmajUw/x+ZkvsuPBwE9AT5/2aBBqPgwQ6xAsVQLxuXoHi2MwzgEW2wtnm5tji4eViCGr+My47Yk9KRqZPGI7VfKSEWlRKgNlSDbjlfYNey1RD6ILq1PR2s9b2b/o+mXDmyvLuL27jJAzvLm362wC2fz/I/QoYKz2TI3E0w6V/A7bLOa3CarjvpVF640qFn42BsP1OEJ8xzh00XTkNDT8ibo3JbyaQvrBbT4YEopkvDJAeP4C+ci3tKN1z7TpRFk/xYAYn9UYNgzk8lAZ0PpJnaZw35UF/ZY9UXFYKIAU4aPlMBR4PwjlLkUeDibKXayDdHHR7e9xxursoZWFFy/401eDFUkDDncwAstQCR0jPqJZoG0mjw5oN8SeEzC13UkaXRbXKHIvhSz++Jy+AzCl6aUcbKTSXgI4gWWu9lqgUIvWsW35taig== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4217.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(376002)(396003)(346002)(366004)(136003)(76116006)(66946007)(6486002)(21615005)(110136005)(54906003)(83380400001)(36756003)(66476007)(8936002)(316002)(8676002)(33656002)(9326002)(66556008)(64756008)(166002)(66446008)(71200400001)(53546011)(6506007)(4326008)(478600001)(5660300002)(66574015)(966005)(2616005)(2906002)(186003)(122000001)(86362001)(6512007)(38100700002)(44832011)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?bU9FckVZV0xDNGQzVHlmOUxtR25HUEFqc2RLeEVUcmlBM2dQaU5rM05MMjhE?= =?utf-8?B?WnZFTFFuR2Q0SVVVbnFtcHltR0pLaEhZbGg0bkM3Vk1KL3lwZXQ5V2NTVndP?= =?utf-8?B?WWJWRnBUUW9wckx5dTZZcUVVQ2NRTEdvL0Y2dE40aDdQUU9jRWRRQmJvWlV1?= =?utf-8?B?UzUzN1pTL2VvQzdLMWNPM0twb0psQi9FNkFNYXJqMmxicFVFb2Rna0VCR2Zl?= =?utf-8?B?VjErYW1VZ0w5Uzd3aGdKVXdIaVVtTGVDY2doVDNPVUFIb1lrQzEzaDhUS2ZJ?= =?utf-8?B?dzNPdjI2MlNmYkNkMjJobkdWZE01UEdDcGtvV0lsSGZDLzVSOGFJSlZKQUhX?= =?utf-8?B?Ull0Qk8yVDhSZHc3M0hKVTh3b0FsVTZveFVzSFIyT21rREx0T05WVjEvbzRU?= =?utf-8?B?Nm11bjRXbzQvWU00RHNpZWdINVBnbUs5bURwMnhHK0V4ZnVHU0xVU1lWWXFY?= =?utf-8?B?NkRWL1Z6WUVoNHhEL3hNd0EvUTUvSjdTMmRsY0R6cTdhMm9McS9xVnZGTHNJ?= =?utf-8?B?cFVnUFozOUpyQkQvT21xVUlaeDdNTVhhQWM4K25TcG9rMDFHdzkyVkdJOW9P?= =?utf-8?B?S2dtd2NKVStobnF5bjREUk9FVGRRTGFTMmJXN3VDUGg2NGJING9kNFJTN2E2?= =?utf-8?B?c094RHR1NEEyNThMRHlEeHpSNUJGVENiWWt0K3JObkxGM01WOTdRWHo1L2RE?= =?utf-8?B?Nm0vb3ZxaHY5YWtCZXZTK2ZGUHdxVGg4WmZQSy9GV2dSRVV1bGZweE9GVm8y?= =?utf-8?B?ZnN5Wm5EZUx3Z3RMdzJ5anIveWdnSnZtSTVML2RaMStpR3hNckhZSEE3SFBq?= =?utf-8?B?ckMwSElLSVFJV2Jhc2pLbi91a2FhbjZCSUNmcXBlbVhDeEdoOHBaWXpzK21N?= =?utf-8?B?S1ZIOFFYbXgrYS9JeHBQNWc3NThFMnpZdWsvTStnLytLdXdnU0xwRm9rNVJh?= =?utf-8?B?VTZrSHBqRnR5NGk0NjBsRjhIRHYrRWU2TEdTSDRHL2cwY252aG00MGtRell2?= =?utf-8?B?UncyL2tNRkIzekdsK3k5WnF0cmtXcVc5S0ZZZEQ0anVjdEljUkJtU25Wa2hr?= =?utf-8?B?clJwTi9LQjJLMnY0VDAxYkZMUEFZRVgxelNvOTllYngvTERYM0llRnV6MmhW?= =?utf-8?B?ZjNPZHNVMEEyMVlHa3BEVzA1b3hPZXF1NFpMOHZHR2dKYlRjblZEZXVEY2dz?= =?utf-8?B?RFh0L1NDZi84WGx0eXhzOEIzelVVVllNVm5JcGtIcVQyU2piS3ZLdlhCTngv?= =?utf-8?B?LzNqNEdERkhXRUlsREVKNmNXQjdhd0hMZndwT1REbGhhcld4a1NjL3ZUOEVX?= =?utf-8?B?bEdwVG9yaUxjQWJWYVBZSmhOZmJsN3loRnZWL2ZhWlN2TmphajVPaDJnN2tl?= =?utf-8?B?bi9CVTVOdWFjOTlKNFB2bWY4NUJWRitSemZDaXQrQlFqbHNIQURFRFd2Ui83?= =?utf-8?B?TWIzVzdFOEtqOXgxaHdqUDY0b0xEc2YxTFlzdUwxL0Z4d0UrV3FXbzNNaTBu?= =?utf-8?B?blU4dFMydU8rMWlVQTRqTXowNTJNOHYyY2d4TWlJakViS0dsdFY5eFZka1dV?= =?utf-8?B?dE5jQ2FEemd4OExOcHI0KzFTMjlFbm5xZUVTU1BUYU1XZEhqeXI1dkhRSm9p?= =?utf-8?B?Slp4bVozR2pvSkp1cHFQbVdhOHBqOGFVV2dIeGZvYXRzb1dDQjBkVlhjWVVT?= =?utf-8?B?MUNWc2xqdisyUHg5Wm5lTzZqUzVBeHZJMHN0SWdQUHZibU9jcjhiVERuVmkz?= =?utf-8?B?UnlrM1NzdzFTZzVQbHJFZjJjcWdiS3dReTJFS3J0bGh3MTJoV01ycnJEVTlM?= =?utf-8?B?K1dGbW45RkNmcHBRQ3lCR0YyMkxybTc3VFdTRnR6ZTFuS1ZHUGgxT3FjZzVW?= =?utf-8?B?UzlUR3NkSWZtK1hhNEhPTlJxOHpDc3RHMkNVQXNBbnIwbUE9PQ==?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CE823989C988422AB50872EF44D172C0ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4217.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2c955005-8181-4e43-17b4-08d91ace2a44 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2021 13:58:22.3107 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wQ0i8pi4bIVF/3vCVt+6722OJrCPUCKUEO/0y3BuQQ8q1W4WViVhynY3dHNXkmAappouQahGWKo0fnWAOfd8Q2ef1b7nm0PBgSKoqGdKc2wGShGMljg5uL6h5AqgKDnd X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2459 Archived-At: Subject: Re: [AVTCORE] Francesca Palombini's No Objection on draft-ietf-avtcore-multi-party-rtt-mix-18: (with COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2021 13:58:34 -0000 --_000_CE823989C988422AB50872EF44D172C0ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClNwZW5jZXI6IHRoYW5rcyBmb3IgcHV0dGluZyBpbnRvIHdvcmRzIHdoYXQgbXkgdW5l YXNpbmVzcyB3aXRoIHRoZSBjdXJyZW50IHRleHQgd2FzLiBSZXBocmFzaW5nIGluIHRoYXQgd2F5 IHdvdWxkIGFkZHJlc3MgbXkgcG9pbnQuDQoNCk90aGVyd2lzZSB5ZXMsIEkgYmVsaWV2ZSBzb21l IHRleHQgd291bGQgYmUgbmVjZXNzYXJ5IHRvIGNsYXJpZnkgdGhhdCB0aGUgTVVTVCBpcyByZWFs bHkgYWJvdXQg4oCccGFyc2luZyBhbmQgdW5kZXJzdGFuZGluZyB0aGUgY29udHJvbCBjb2Rl4oCd LCBpbiBvcmRlciB0byBpZ25vcmUgdW5zdXBwb3J0ZWQgb25lcy4NCg0KRnJhbmNlc2NhDQoNCkZy b206IFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGIDxzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNv bT4NCkRhdGU6IFdlZG5lc2RheSwgMTkgTWF5IDIwMjEgYXQgMTU6NDgNClRvOiBHdW5uYXIgSGVs bHN0csO2bSA8Z3VubmFyLmhlbGxzdHJvbUBnaGFjY2Vzcy5zZT4NCkNjOiBGcmFuY2VzY2EgUGFs b21iaW5pIDxmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNvbT4sIFRoZSBJRVNHIDxpZXNn QGlldGYub3JnPiwgImF2dGNvcmUtY2hhaXJzQGlldGYub3JnIiA8YXZ0Y29yZS1jaGFpcnNAaWV0 Zi5vcmc+LCAiZHJhZnQtaWV0Zi1hdnRjb3JlLW11bHRpLXBhcnR5LXJ0dC1taXhAaWV0Zi5vcmci IDxkcmFmdC1pZXRmLWF2dGNvcmUtbXVsdGktcGFydHktcnR0LW1peEBpZXRmLm9yZz4sIElFVEYg QVZUQ29yZSBXRyA8YXZ0QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtBVlRDT1JFXSBGcmFuY2Vz Y2EgUGFsb21iaW5pJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtYXZ0Y29yZS1tdWx0aS1w YXJ0eS1ydHQtbWl4LTE4OiAod2l0aCBDT01NRU5UKQ0KDQpJIGFwb2xvZ2l6ZSBmb3IgYXNraW5n LCBidXQgLi4uDQoNCk9uIFR1ZSwgTWF5IDE4LCAyMDIxIGF0IDQ6NDMgUE0gR3VubmFyIEhlbGxz dHLDtm0gPGd1bm5hci5oZWxsc3Ryb21AZ2hhY2Nlc3Muc2U8bWFpbHRvOmd1bm5hci5oZWxsc3Ry b21AZ2hhY2Nlc3Muc2U+PiB3cm90ZToNCkZyYW5jZXNjYSwNCg0KdGhhbmsgeW91IGZvciB5b3Vy IHJldmlldy4gSSB3aWxsIGFuc3dlciB5b3VyIHF1ZXN0aW9uIDYgaGVyZSwgYW5kDQpmb2xsb3cg dXAgc29vbiB3aXRoIGEgbmV3IHZlcnNpb24gd2l0aCBhY3Rpb25zIG9uIGFsbCBjb21tZW50cy4N Cg0KRGVuIDIwMjEtMDUtMTgga2wuIDIyOjM0LCBza3JldiBGcmFuY2VzY2EgUGFsb21iaW5pIHZp YSBEYXRhdHJhY2tlcjoNCj4gRnJhbmNlc2NhIFBhbG9tYmluaSBoYXMgZW50ZXJlZCB0aGUgZm9s bG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gZHJhZnQtaWV0Zi1hdnRjb3JlLW11bHRpLXBh cnR5LXJ0dC1taXgtMTg6IE5vIE9iamVjdGlvbg0KPg0KPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFz ZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCj4gZW1haWwg YWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8g Y3V0IHRoaXMNCj4gaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+DQo+DQo+IFBs ZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNz LWNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgRElTQ1VTUyBhbmQg Q09NTUVOVCBwb3NpdGlvbnMuDQo+DQo+DQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhl ciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1hdnRjb3JlLW11bHRpLXBhcnR5LXJ0dC1taXgv DQo+DQo+DQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K Pg0KPiBUaGFuayB5b3UgZm9yIHRoZSB3b3JrIG9uIHRoaXMgZG9jdW1lbnQuIEkgaGF2ZSBzb21l IG1pbm9yIG5vbi1ibG9ja2luZw0KPiBjb21tZW50cyAoZmVlbCBmcmVlIHRvIHRha2UgdGhlbSBv ciBsZWF2ZSB0aGVtKSwgYnV0IEknZCBsaWtlIHNvbWUgcmVzcG9uc2UgdG8NCj4gcG9pbnQgNi4g YWJvdXQgdGhlIG5vcm1hdGl2ZSBNVVNULg0KPg0KPiBGcmFuY2VzY2ENCi4uLi4NCj4gNi4gLS0t LS0NCj4NCj4gICAgIHRoZSBzdHJlYW0uICBTb21lIG9mIHRoZW0gYXJlIG9wdGlvbmFsLiAgSW1w bGVtZW50YXRpb25zIE1VU1QgYmUgYWJsZQ0KPiAgICAgdG8gaWdub3JlIG9wdGlvbmFsIGNvbnRy b2wgY29kZXMgdGhhdCB0aGV5IGRvIG5vdCBzdXBwb3J0Lg0KPg0KPiBGUDogSSBhbSByZWFsbHkg dW5zdXJlIGhvdyB0aGlzIE1VU1QgY2FuIGJlIHZlcmlmaWVkIGZvciBpbnRlcm9wZXJhYmlsaXR5 Lg0KPiBNYXliZSB0aGlzIGRvZXMgbm90IG5lZWQgdG8gYmUgYSBCQ1AgMTQgTVVTVD8NCg0KR3Vu bmFyLA0KDQpXaGVuIEkgcmVhZCB5b3VyIHJlc3BvbnNlIHRvIEZyYW5jZXNjYSdzIGNvbW1lbnQs IG15IG5leHQgcXVlc3Rpb24gd2FzIHdoZXRoZXIgYW4gaW1wbGVtZW50YXRpb24gc2hvdWxkIGFs d2F5cyBpZ25vcmUgb3B0aW9uYWwgY29udHJvbCBjb2RlcyB0aGF0IHRoZXkgZG8gbm90IHN1cHBv cnQsIGlmICpub3QqIGlnbm9yaW5nIHRoZW0ganVzdCBjYXVzZSBwcm9ibGVtcywgZGlzcGxheXMg Z2FyYmFnZSBjaGFyYWN0ZXJzLCBldGMuDQoNCklmIHRoYXQncyBjb3JyZWN0LCBJJ20gbm90IEZy YW5jZXNjYSwgb2YgY291cnNlLCBidXQgSSdkIHRoaW5rICJJbXBsZW1lbnRhdGlvbnMgTVVTVCBp Z25vcmUgb3B0aW9uYWwgY29udHJvbCBjb2RlcyB0aGF0IHRoZXkgZG8gbm90IHN1cHBvcnQiIHdv dWxkIGJlIHZlcmlmaWFibGUgZm9yIGludGVyb3BlcmFiaWxpdHksIGFuZCB3b3VsZCBqdXN0aWZ5 IGEgQkNQIDE0IE1VU1QuLg0KDQpCZXN0LA0KDQpTcGVuY2VyDQoNClllcywgdGhpcyBNVVNUIGlz IGludGVuZGVkIHRvIGJlIGEgbm9ybWF0aXZlIE1VU1QuIEFuZCBpdCBpcyB2ZXJ5DQppbXBvcnRh bnQgYnV0IG5vdCB0aGF0IGNvbXBsaWNhdGVkIHRvIHByb3Blcmx5IGlnbm9yZSB1bnN1cHBvcnRl ZA0KY29udHJvbCBjb2Rlcy4NCg0KVGhlIGNvbnRyb2wgY29kZXMgYXJlIHNwZWNpZmllZCBpbiBJ VFUtVCBULjE0MCwgaW4gdHVybiByZWZlcmVuY2luZyB0bw0KSVNPIDY0MjkuIFRoZSBjb250cm9s IGNvZGVzIG9mdGVuIGNvbnNpc3Qgb2YgYSBzcGVjaWFsIGxlYWRpbmcNCmNoYXJhY3RlciwgZm9s bG93ZWQgYnkgYSBwYXJhbWV0ZXIgY29uc2lzdGluZyBvZiBub3JtYWwgdGV4dCBjaGFyYWN0ZXJz LA0KYW5kIHRoZW4gYSBmaW5hbCBzcGVjaWFsIGNoYXJhY3Rlci4NCg0KSWdub3JpbmcgYW4gdW5z dXBwb3J0ZWQgY29udHJvbCBjb2RlIG1lYW5zIHRoYXQgdGhlIGFwcCBuZWVkcyB0bw0KdW5kZXJz dGFuZCB0aGUgc3RydWN0dXJlIG9mIGNvbnRyb2wgY29kZXMsIHNvIHRoYXQgaXQgaWdub3JlcyBl dmVyeXRoaW5nDQpmcm9tIHRoZSBsZWFkaW5nIHNwZWNpYWwgY2hhcmFjdGVyIHRvIGFuZCBpbmNs dWRpbmcgdGhlIGZpbmFsIHNwZWNpYWwNCmNoYXJhY3Rlci4NCg0KSXQgd291bGQgYmUgaW5jb3Jy ZWN0IGFuZCBjYXVzZSBnYXJiYWdlIGluIHRoZSBkaXNwbGF5IG9yIGV2ZW4NCm1hbGZ1bmN0aW9u IGlmIGl0IGp1c3QgaWdub3JlZCB0aGUgbGVhZGluZyBzcGVjaWFsIGNoYXJhY3RlciBhbmQgdGhl bg0KaW50ZXJwcmV0ZWQgdGhlIGNoYXJhY3RlcnMgaW4gdGhlIHBhcmFtZXRlciBhcyBpZiBpdCB3 YXMgdGV4dCBhbmQgdHJpZWQNCnRvIHByZXNlbnQgaXQuDQoNClRoZSBjb250cm9sIGNvZGVzIGNh biBpbXBseSBjaGFuZ2UgaW4gY29sb3Igb3IgYmxpbmtpbmcgb3Igb3RoZXIgdmlzaWJsZQ0KZWZm ZWN0cyBpbiB0aGUgdGV4dCwgYW5kIGl0IGlzIHNhaWQgdGhhdCBzdWNoIGVmZmVjdHMgYXJlIG9w dGlvbmFsLg0KDQoNCldvdWxkIG1vcmUgZXhwbGFpbmluZyB0ZXh0IGJlIHJlcXVpcmVkIGZvciB0 aGlzIHNlY3Rpb24/DQoNCg0KUmVnYXJkcw0KDQpHdW5uYXINCg0KPg0KPg0KPg0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBBdWRpby9WaWRlbyBU cmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KPiBhdnRAaWV0Zi5vcmc8bWFpbHRvOmF2dEBpZXRm Lm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnQNCg0KLS0N Ckd1bm5hciBIZWxsc3Ryw7ZtDQpHSEFjY2Vzcw0KZ3VubmFyLmhlbGxzdHJvbUBnaGFjY2Vzcy5z ZTxtYWlsdG86Z3VubmFyLmhlbGxzdHJvbUBnaGFjY2Vzcy5zZT4NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBD b3JlIE1haW50ZW5hbmNlDQphdnRAaWV0Zi5vcmc8bWFpbHRvOmF2dEBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQo= --_000_CE823989C988422AB50872EF44D172C0ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5TcGVuY2VyOiB0aGFua3MgZm9yIHB1dHRpbmcgaW50byB3b3Jk cyB3aGF0IG15IHVuZWFzaW5lc3Mgd2l0aCB0aGUgY3VycmVudCB0ZXh0IHdhcy4gUmVwaHJhc2lu ZyBpbiB0aGF0IHdheSB3b3VsZCBhZGRyZXNzIG15IHBvaW50LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5PdGhlcndpc2UgeWVz LCBJIGJlbGlldmUgc29tZSB0ZXh0IHdvdWxkIGJlIG5lY2Vzc2FyeSB0byBjbGFyaWZ5IHRoYXQg dGhlIE1VU1QgaXMgcmVhbGx5IGFib3V0IOKAnHBhcnNpbmcgYW5kIHVuZGVyc3RhbmRpbmcgdGhl IGNvbnRyb2wgY29kZeKAnSwgaW4gb3JkZXIgdG8gaWdub3JlIHVuc3VwcG9ydGVkIG9uZXMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPkZyYW5jZXNjYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5TcGVuY2VyIERhd2tpbnMgYXQgSUVURiAmbHQ7c3Bl bmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2Rh eSwgMTkgTWF5IDIwMjEgYXQgMTU6NDg8YnI+DQo8Yj5UbzogPC9iPkd1bm5hciBIZWxsc3Ryw7Zt ICZsdDtndW5uYXIuaGVsbHN0cm9tQGdoYWNjZXNzLnNlJmd0Ozxicj4NCjxiPkNjOiA8L2I+RnJh bmNlc2NhIFBhbG9tYmluaSAmbHQ7ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb20mZ3Q7 LCBUaGUgSUVTRyAmbHQ7aWVzZ0BpZXRmLm9yZyZndDssICZxdW90O2F2dGNvcmUtY2hhaXJzQGll dGYub3JnJnF1b3Q7ICZsdDthdnRjb3JlLWNoYWlyc0BpZXRmLm9yZyZndDssICZxdW90O2RyYWZ0 LWlldGYtYXZ0Y29yZS1tdWx0aS1wYXJ0eS1ydHQtbWl4QGlldGYub3JnJnF1b3Q7ICZsdDtkcmFm dC1pZXRmLWF2dGNvcmUtbXVsdGktcGFydHktcnR0LW1peEBpZXRmLm9yZyZndDssIElFVEYgQVZU Q29yZQ0KIFdHICZsdDthdnRAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBb QVZUQ09SRV0gRnJhbmNlc2NhIFBhbG9tYmluaSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm LWF2dGNvcmUtbXVsdGktcGFydHktcnR0LW1peC0xODogKHdpdGggQ09NTUVOVCk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5J IGFwb2xvZ2l6ZSBmb3IgYXNraW5nLCBidXQgLi4uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiBUdWUsIE1heSAxOCwgMjAyMSBhdCA0OjQzIFBNIEd1 bm5hciBIZWxsc3Ryw7ZtICZsdDs8YSBocmVmPSJtYWlsdG86Z3VubmFyLmhlbGxzdHJvbUBnaGFj Y2Vzcy5zZSI+Z3VubmFyLmhlbGxzdHJvbUBnaGFjY2Vzcy5zZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+RnJhbmNlc2NhLDxicj4NCjxicj4NCnRoYW5rIHlvdSBm b3IgeW91ciByZXZpZXcuIEkgd2lsbCBhbnN3ZXIgeW91ciBxdWVzdGlvbiA2IGhlcmUsIGFuZCA8 YnI+DQpmb2xsb3cgdXAgc29vbiB3aXRoIGEgbmV3IHZlcnNpb24gd2l0aCBhY3Rpb25zIG9uIGFs bCBjb21tZW50cy48YnI+DQo8YnI+DQpEZW4gMjAyMS0wNS0xOCBrbC4gMjI6MzQsIHNrcmV2IEZy YW5jZXNjYSBQYWxvbWJpbmkgdmlhIERhdGF0cmFja2VyOjxicj4NCiZndDsgRnJhbmNlc2NhIFBh bG9tYmluaSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3I8YnI+ DQomZ3Q7IGRyYWZ0LWlldGYtYXZ0Y29yZS1tdWx0aS1wYXJ0eS1ydHQtbWl4LTE4OiBObyBPYmpl Y3Rpb248YnI+DQomZ3Q7PGJyPg0KJmd0OyBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRo ZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGw8YnI+DQomZ3Q7IGVtYWlsIGFk ZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1 dCB0aGlzPGJyPg0KJmd0OyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLik8YnI+DQom Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgUGxlYXNlIHJlZmVyIHRvIDxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbCIgdGFyZ2V0 PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1j cml0ZXJpYS5odG1sPC9hPjxicj4NCiZndDsgZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgRElT Q1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7 IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUg Zm91bmQgaGVyZTo8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtYXZ0Y29yZS1tdWx0aS1wYXJ0eS1ydHQtbWl4LyIgdGFyZ2V0PSJf YmxhbmsiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1hdnRj b3JlLW11bHRpLXBhcnR5LXJ0dC1taXgvPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0 Ozxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgQ09NTUVOVDo8YnI+DQomZ3Q7IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGFuayB5b3UgZm9yIHRoZSB3b3JrIG9u IHRoaXMgZG9jdW1lbnQuIEkgaGF2ZSBzb21lIG1pbm9yIG5vbi1ibG9ja2luZzxicj4NCiZndDsg Y29tbWVudHMgKGZlZWwgZnJlZSB0byB0YWtlIHRoZW0gb3IgbGVhdmUgdGhlbSksIGJ1dCBJJ2Qg bGlrZSBzb21lIHJlc3BvbnNlIHRvPGJyPg0KJmd0OyBwb2ludCA2LiBhYm91dCB0aGUgbm9ybWF0 aXZlIE1VU1QuPGJyPg0KJmd0Ozxicj4NCiZndDsgRnJhbmNlc2NhPGJyPg0KLi4uLjxicj4NCiZn dDsgNi4gLS0tLS08YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7dGhlIHN0 cmVhbS4mbmJzcDsgU29tZSBvZiB0aGVtIGFyZSBvcHRpb25hbC4mbmJzcDsgSW1wbGVtZW50YXRp b25zIE1VU1QgYmUgYWJsZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO3RvIGlnbm9yZSBv cHRpb25hbCBjb250cm9sIGNvZGVzIHRoYXQgdGhleSBkbyBub3Qgc3VwcG9ydC48YnI+DQomZ3Q7 PGJyPg0KJmd0OyBGUDogSSBhbSByZWFsbHkgdW5zdXJlIGhvdyB0aGlzIE1VU1QgY2FuIGJlIHZl cmlmaWVkIGZvciBpbnRlcm9wZXJhYmlsaXR5Ljxicj4NCiZndDsgTWF5YmUgdGhpcyBkb2VzIG5v dCBuZWVkIHRvIGJlIGEgQkNQIDE0IE1VU1Q/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5HdW5uYXIsJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPldoZW4gSSByZWFkIHlvdXIgcmVz cG9uc2UgdG8gRnJhbmNlc2NhJ3MgY29tbWVudCwgbXkgbmV4dCBxdWVzdGlvbiB3YXMgd2hldGhl ciBhbiBpbXBsZW1lbnRhdGlvbiBzaG91bGQgYWx3YXlzIGlnbm9yZSBvcHRpb25hbCBjb250cm9s IGNvZGVzIHRoYXQgdGhleSBkbyBub3Qgc3VwcG9ydCwgaWYgKm5vdCogaWdub3JpbmcgdGhlbSBq dXN0IGNhdXNlIHByb2JsZW1zLA0KIGRpc3BsYXlzIGdhcmJhZ2UgY2hhcmFjdGVycywgZXRjLiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5J ZiB0aGF0J3MgY29ycmVjdCwgSSdtIG5vdCBGcmFuY2VzY2EsIG9mIGNvdXJzZSwgYnV0IEknZCB0 aGluayAmcXVvdDtJbXBsZW1lbnRhdGlvbnMgTVVTVCBpZ25vcmUgb3B0aW9uYWwgY29udHJvbCBj b2RlcyB0aGF0IHRoZXkgZG8gbm90IHN1cHBvcnQmcXVvdDsgd291bGQgYmUgdmVyaWZpYWJsZSBm b3IgaW50ZXJvcGVyYWJpbGl0eSwgYW5kIHdvdWxkIGp1c3RpZnkgYSBCQ1AgMTQNCiBNVVNULi4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ QmVzdCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ U3BlbmNlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij5ZZXMsIHRoaXMgTVVTVCBpcyBpbnRlbmRlZCB0byBiZSBhIG5vcm1hdGl2ZSBNVVNU LiBBbmQgaXQgaXMgdmVyeQ0KPGJyPg0KaW1wb3J0YW50IGJ1dCBub3QgdGhhdCBjb21wbGljYXRl ZCB0byBwcm9wZXJseSBpZ25vcmUgdW5zdXBwb3J0ZWQgPGJyPg0KY29udHJvbCBjb2Rlcy48YnI+ DQo8YnI+DQpUaGUgY29udHJvbCBjb2RlcyBhcmUgc3BlY2lmaWVkIGluIElUVS1UIFQuMTQwLCBp biB0dXJuIHJlZmVyZW5jaW5nIHRvIDxicj4NCklTTyA2NDI5LiBUaGUgY29udHJvbCBjb2RlcyBv ZnRlbiBjb25zaXN0IG9mIGEgc3BlY2lhbCBsZWFkaW5nIDxicj4NCmNoYXJhY3RlciwgZm9sbG93 ZWQgYnkgYSBwYXJhbWV0ZXIgY29uc2lzdGluZyBvZiBub3JtYWwgdGV4dCBjaGFyYWN0ZXJzLCA8 YnI+DQphbmQgdGhlbiBhIGZpbmFsIHNwZWNpYWwgY2hhcmFjdGVyLjxicj4NCjxicj4NCklnbm9y aW5nIGFuIHVuc3VwcG9ydGVkIGNvbnRyb2wgY29kZSBtZWFucyB0aGF0IHRoZSBhcHAgbmVlZHMg dG8gPGJyPg0KdW5kZXJzdGFuZCB0aGUgc3RydWN0dXJlIG9mIGNvbnRyb2wgY29kZXMsIHNvIHRo YXQgaXQgaWdub3JlcyBldmVyeXRoaW5nIDxicj4NCmZyb20gdGhlIGxlYWRpbmcgc3BlY2lhbCBj aGFyYWN0ZXIgdG8gYW5kIGluY2x1ZGluZyB0aGUgZmluYWwgc3BlY2lhbCA8YnI+DQpjaGFyYWN0 ZXIuPGJyPg0KPGJyPg0KSXQgd291bGQgYmUgaW5jb3JyZWN0IGFuZCBjYXVzZSBnYXJiYWdlIGlu IHRoZSBkaXNwbGF5IG9yIGV2ZW4gPGJyPg0KbWFsZnVuY3Rpb24gaWYgaXQganVzdCBpZ25vcmVk IHRoZSBsZWFkaW5nIHNwZWNpYWwgY2hhcmFjdGVyIGFuZCB0aGVuIDxicj4NCmludGVycHJldGVk IHRoZSBjaGFyYWN0ZXJzIGluIHRoZSBwYXJhbWV0ZXIgYXMgaWYgaXQgd2FzIHRleHQgYW5kIHRy aWVkIDxicj4NCnRvIHByZXNlbnQgaXQuPGJyPg0KPGJyPg0KVGhlIGNvbnRyb2wgY29kZXMgY2Fu IGltcGx5IGNoYW5nZSBpbiBjb2xvciBvciBibGlua2luZyBvciBvdGhlciB2aXNpYmxlIDxicj4N CmVmZmVjdHMgaW4gdGhlIHRleHQsIGFuZCBpdCBpcyBzYWlkIHRoYXQgc3VjaCBlZmZlY3RzIGFy ZSBvcHRpb25hbC48YnI+DQo8YnI+DQo8YnI+DQpXb3VsZCBtb3JlIGV4cGxhaW5pbmcgdGV4dCBi ZSByZXF1aXJlZCBmb3IgdGhpcyBzZWN0aW9uPzxicj4NCjxicj4NCjxicj4NClJlZ2FyZHM8YnI+ DQo8YnI+DQpHdW5uYXI8YnI+DQo8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQom Z3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K Jmd0OyBBdWRpby9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZTxicj4NCiZndDsgPGEg aHJlZj0ibWFpbHRvOmF2dEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmF2dEBpZXRmLm9yZzwv YT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vYXZ0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9hdnQ8L2E+PGJyPg0KPGJyPg0KLS0gPGJyPg0KR3VubmFyIEhlbGxzdHLDtm08YnI+DQpH SEFjY2Vzczxicj4NCjxhIGhyZWY9Im1haWx0bzpndW5uYXIuaGVsbHN0cm9tQGdoYWNjZXNzLnNl IiB0YXJnZXQ9Il9ibGFuayI+Z3VubmFyLmhlbGxzdHJvbUBnaGFjY2Vzcy5zZTwvYT48YnI+DQo8 YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CkF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlPGJyPg0KPGEgaHJlZj0ibWFp bHRvOmF2dEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmF2dEBpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0PC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_CE823989C988422AB50872EF44D172C0ericssoncom_-- From nobody Wed May 19 12:35:51 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30CC83A1C88; Wed, 19 May 2021 12:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuFG6zx7VeUW; Wed, 19 May 2021 12:35:33 -0700 (PDT) Received: from smtp.egensajt.se (smtp.egensajt.se [194.68.80.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C1D63A1C66; Wed, 19 May 2021 12:35:31 -0700 (PDT) Received: from [192.168.2.137] (h77-53-37-81.cust.a3fiber.se [77.53.37.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 93A962094C; Wed, 19 May 2021 21:35:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1621452927; bh=jC0vDAfAjvWoeOrZdGAeBzChZOeWH5ZN2njPHuMv6kA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=k5Mo1WEkM1Ig3m4sjse//C2iLO7LIzeR4DlMR3puOmn3VXjwjhFfdJc97FS/d4HBY YDfSp/VilMFJJfbADD/GW70J8K4/EFuCdY35r9uS4ulJP0YaVTu3R1ieEjjhbSCYhS viwMqUxU7OLkr+1E8YHiowM1in5qHaj5lPbNxuwk= To: Spencer Dawkins at IETF Cc: Francesca Palombini , The IESG , avtcore-chairs@ietf.org, draft-ietf-avtcore-multi-party-rtt-mix@ietf.org, IETF AVTCore WG References: <162137008198.8563.14104995910062091869@ietfa.amsl.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Wed, 19 May 2021 21:35:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B3324FE3971859D5B905FA78" Content-Language: sv Archived-At: Subject: Re: [AVTCORE] Francesca Palombini's No Objection on draft-ietf-avtcore-multi-party-rtt-mix-18: (with COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2021 19:35:49 -0000 This is a multi-part message in MIME format. --------------B3324FE3971859D5B905FA78 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Spencer and Francesca, Thanks for the edit proposal. Since Francesca accepts it, I will include it in next version. If my further comments inline do not lead to one more change. Den 2021-05-19 kl. 15:48, skrev Spencer Dawkins at IETF: > I apologize for asking, but ... > > On Tue, May 18, 2021 at 4:43 PM Gunnar Hellström > > > wrote: > > Francesca, > > thank you for your review. I will answer your question 6 here, and > follow up soon with a new version with actions on all comments. > > Den 2021-05-18 kl. 22:34, skrev Francesca Palombini via Datatracker: > > Francesca Palombini has entered the following ballot position for > > draft-ietf-avtcore-multi-party-rtt-mix-18: No Objection > > > > When responding, please keep the subject line intact and reply > to all > > email addresses included in the To and CC lines. (Feel free to > cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/ > > > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > > ---------------------------------------------------------------------- > > > > Thank you for the work on this document. I have some minor > non-blocking > > comments (feel free to take them or leave them), but I'd like > some response to > > point 6. about the normative MUST. > > > > Francesca > .... > > 6. ----- > > > >     the stream.  Some of them are optional. Implementations MUST > be able > >     to ignore optional control codes that they do not support. > > > > FP: I am really unsure how this MUST can be verified for > interoperability. > > Maybe this does not need to be a BCP 14 MUST? > > > Gunnar, > > When I read your response to Francesca's comment, my next question was > whether an implementation should always ignore optional control codes > that they do not support, if *not* ignoring them just cause problems, > displays garbage characters, etc. > > If that's correct, I'm not Francesca, of course, but I'd think > "Implementations MUST ignore optional control codes that they do not > support" would be verifiable for interoperability, and would justify a > BCP 14 MUST.. Yes, that is the case and the edit looks good. I forgot to comment on the kernel of Francesca's comment. "Can it be verified"? Yes, a test generator can include control codes of the different specified types, and the verification would be that the ones supported have the intentional effect and the unsupported ones do not cause any visible effects and do not cause malfunction in the receiver. As usual with testing you need to restrict the variations of the values in these control codes to a realistic number. Is "ignore" a too weak word here. It is an active discarding with knowledge about the syntax of the control codes that is required, so that everything from start to end can be discarded. Would it be better to change "ignore" to "discard" or "skip"? Regards Gunnar > > Best, > > Spencer > > Yes, this MUST is intended to be a normative MUST. And it is very > important but not that complicated to properly ignore unsupported > control codes. > > The control codes are specified in ITU-T T.140, in turn > referencing to > ISO 6429. The control codes often consist of a special leading > character, followed by a parameter consisting of normal text > characters, > and then a final special character. > > Ignoring an unsupported control code means that the app needs to > understand the structure of control codes, so that it ignores > everything > from the leading special character to and including the final special > character. > > It would be incorrect and cause garbage in the display or even > malfunction if it just ignored the leading special character and then > interpreted the characters in the parameter as if it was text and > tried > to present it. > > The control codes can imply change in color or blinking or other > visible > effects in the text, and it is said that such effects are optional. > > > Would more explaining text be required for this section? > > > Regards > > Gunnar > > > > > > > > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > -- > Gunnar Hellström > GHAccess > gunnar.hellstrom@ghaccess.se > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > -- Gunnar Hellström GHAccess gunnar.hellstrom@ghaccess.se --------------B3324FE3971859D5B905FA78 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Spencer and Francesca,

Thanks for the edit proposal. Since Francesca accepts it, I will include it in next version.

If my further comments inline do not lead to one more change.

Den 2021-05-19 kl. 15:48, skrev Spencer Dawkins at IETF:
I apologize for asking, but ... 

On Tue, May 18, 2021 at 4:43 PM Gunnar Hellström <gunnar.hellstrom@ghaccess.se> wrote:
Francesca,

thank you for your review. I will answer your question 6 here, and
follow up soon with a new version with actions on all comments.

Den 2021-05-18 kl. 22:34, skrev Francesca Palombini via Datatracker:
> Francesca Palombini has entered the following ballot position for
> draft-ietf-avtcore-multi-party-rtt-mix-18: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for the work on this document. I have some minor non-blocking
> comments (feel free to take them or leave them), but I'd like some response to
> point 6. about the normative MUST.
>
> Francesca
....
> 6. -----
>
>     the stream.  Some of them are optional.  Implementations MUST be able
>     to ignore optional control codes that they do not support.
>
> FP: I am really unsure how this MUST can be verified for interoperability.
> Maybe this does not need to be a BCP 14 MUST?

Gunnar, 

When I read your response to Francesca's comment, my next question was whether an implementation should always ignore optional control codes that they do not support, if *not* ignoring them just cause problems, displays garbage characters, etc. 

If that's correct, I'm not Francesca, of course, but I'd think "Implementations MUST ignore optional control codes that they do not support" would be verifiable for interoperability, and would justify a BCP 14 MUST..

Yes, that is the case and the edit looks good.

I forgot to comment on the kernel of Francesca's comment. "Can it be verified"? Yes, a test generator can include control codes of the different specified types, and the verification would be that the ones supported have the intentional effect and the unsupported ones do not cause any visible effects and do not cause malfunction in the receiver. As usual with testing you need to restrict the variations of the values in these control codes to a realistic number.

Is "ignore" a too weak word here. It is an active discarding with knowledge about the syntax of the control codes that is required, so that everything from start to end can be discarded.

Would it be better to change "ignore" to "discard" or "skip"?

Regards

Gunnar 


Best,

Spencer
 
Yes, this MUST is intended to be a normative MUST. And it is very
important but not that complicated to properly ignore unsupported
control codes.

The control codes are specified in ITU-T T.140, in turn referencing to
ISO 6429. The control codes often consist of a special leading
character, followed by a parameter consisting of normal text characters,
and then a final special character.

Ignoring an unsupported control code means that the app needs to
understand the structure of control codes, so that it ignores everything
from the leading special character to and including the final special
character.

It would be incorrect and cause garbage in the display or even
malfunction if it just ignored the leading special character and then
interpreted the characters in the parameter as if it was text and tried
to present it.

The control codes can imply change in color or blinking or other visible
effects in the text, and it is said that such effects are optional.


Would more explaining text be required for this section?


Regards

Gunnar

>
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt

--
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt
-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se
--------------B3324FE3971859D5B905FA78-- From nobody Wed May 19 14:25:18 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D513A1F73; Wed, 19 May 2021 14:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPyHltyFy5ap; Wed, 19 May 2021 14:25:11 -0700 (PDT) Received: from smtp.egensajt.se (smtp.egensajt.se [194.68.80.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCEFD3A1F7F; Wed, 19 May 2021 14:25:09 -0700 (PDT) Received: from [192.168.2.137] (h77-53-37-81.cust.a3fiber.se [77.53.37.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 4D8BC2002F; Wed, 19 May 2021 23:25:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1621459507; bh=WqmF8knWWxlmtqfdGDnb7Vijc3MRA29zNSE6aRNFsNA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Eq5DLIvK9Y78s5usktEiavkh8x8il45ySaIdrigS72FZztNh+ij/Bn+IRQVDWEKji SThUhy5mp2r1WzEkuolcVlUvsE24FZvBkqyt3QZc4bPfaWL1759MR1ujrHNCHUx1J/ R85Pk0i0x+rhv+T0hndhE1b0DYhb+/a4kbPmp4nA= To: Benjamin Kaduk , The IESG Cc: avtcore-chairs@ietf.org, draft-ietf-avtcore-multi-party-rtt-mix@ietf.org, avt@ietf.org References: <162139279927.706.12647899386073526674@ietfa.amsl.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <0f0350e8-231d-8d1b-d561-a172d68ac4a3@ghaccess.se> Date: Wed, 19 May 2021 23:25:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: <162139279927.706.12647899386073526674@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: sv Archived-At: Subject: Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-ietf-avtcore-multi-party-rtt-mix-18: (with DISCUSS and COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2021 21:25:16 -0000 Benjamin, Thanks for the thorough review. I will respond in multiple pieces, starting with the first parts of the DISCUSS. Den 2021-05-19 kl. 04:53, skrev Benjamin Kaduk via Datatracker: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-avtcore-multi-party-rtt-mix-18: Discuss > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I'm not sure I understand how the examples are consistent with the main > specification, so let's please discuss it to either un-confuse me or fix > the document. > > Section 3.9 seems to say that the oldest (source or redundant) text at > the mixer takes priority when there is text from more than one source > waiting to be sent, but the examples in Section 3.21 seem to show (e.g.) > text received from A at time 20400 that is to be sent as redundancy, > being sent after text from B received at time 20500 (sent as primary). > Is the intent that if there is any primary text, the oldest primary text > is sent first, and only if there is no outstanding primary text do we > consider the redundant text? [GH] You are right. The text in 3.9 i not clear enough. If there is no new text from A, the redundancy of A shall not be sent until 330 ms after the primary text from A was sent. Only if new text arrives from A before 330 ms after the previous text was sent, then both that new text and the redundancy shall be sent, when the new text is the oldest available. So in the example, it is correct to send text from B first. One way to say it is that redundant text shall not participate in the age assessment until it is 330 ms older than when it was last sent. But it shall be included if new text is available and decided to be sent. When composing suitable text from this, we also need to consider that the "CPS" value may puts a limit to how much new text may be sent. We also have the following words last in 3.12: "   The T140blocks saved for transmission as redundant data are assigned    a planned transmission time 330 ms after the current time, but SHOULD    be transmitted earlier if new text for the same source gets in turn    for transmission before that time." So, 3.9 is about interleaving new text and not about making sure that redundancy is sent even when there is no new text.  The text in 3.9 may become correct by deleting the redundancy from the age assessment, and include "CPS" consideration, to result in: "The source with the oldest text received in the mixer  SHALL be next in turn to get all its available unsent text transmitted, as long as it is allowed considering the "CPS" value of the receiver.  Any redundant repetitions of earlier transmitted  text not yet sent the intended number of times SHALL be included as redundant retransmission in the transmission." > > In a related vein, Section 3.10 says that a packet is sent when (among > other things) "330 ms has passed since already transmitted text was > queued for transmission as redundant text". But that doesn't say > anything about the timer being reset by subsequent transmission or > queuing of redundant text, so I'm not sure how in the Section 3.21 > example, we say that transmitting B1 and B2 as redundancy was planned as > 330 ms after packet 105 -- the original B2 was sent in packet 104, so > shouldn't the 330ms start from packet 104's transmission? (The stated > time for this seems to match 330ms after 104, so maybe the "105" is just > a typo?) > > > I also left a note in the comment that there's a remark about "lower > security level" in Section 3.19 that's not really accurate; we should > resolve that in some manner before the document proceeds. > > [GH] -Answers to be continued, Gunnar > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt -- Gunnar Hellström GHAccess gunnar.hellstrom@ghaccess.se From nobody Wed May 19 16:47:35 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A97E3A2419 for ; Wed, 19 May 2021 16:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPaVpJPSoTsC for ; Wed, 19 May 2021 16:47:29 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A08223A2417 for ; Wed, 19 May 2021 16:47:28 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id e2so11251036ljk.4 for ; Wed, 19 May 2021 16:47:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=G9YlRseQHYP7RO4HmsrZvqjbNeisKMLa94En9qJuUAU=; b=CyA+Mv1ELor80D5txXKDVG9ljPjt8iVa2T1FilB7o3qeexs+5uHspRzxhQXEnhV6N5 0IJDub+xZ/mGYC8wCB/Nx5eLhMMHqGcZ0h4t5mUmEAz3FavyqZQXFt6ade3i5KEpZGok stX3pfGpJoE8lKc8Ws9AtMxJgqM13C4UiH8VfcN52l8CwmcY/FN+REOp2GqzlZr832po jiBaSDz3QTeICpsZtPC6b3oAlYIfhD3dcifZfQTvMrWz4A+BA1eDbL3tTcR6YKOY6iVh OJRVowsoe738ylq4mYY1qeAMoVobsc38gdjfsycIjoL4WCXAfhZncw978w2SJzpVlko8 ohbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=G9YlRseQHYP7RO4HmsrZvqjbNeisKMLa94En9qJuUAU=; b=RK2D1U/p8fsrnqsEfbXkKIin0KZ18RCu1NmCPbPJuWCVzGgFmoSlgbseWW6PtgtLQ8 cYfjag6vAxw6zA9POzTBn5pQIA0dE2ep8JwCUjff38zGbPaXMz+G7c2yePFu4RIXGTFD ddySds2e9ciVJfnq6X/1G98LwjuL80QVSL5MBPbwjfWH4nKB9CPon+RIBocE57+zhS6D QtPkBF3/tNFVX812c8b+d1HKQ2ILN8XvhW9klx0CPU/Ucg5wH6q4Iv0QK3SOIpvMgUPt eoUEzI7ZlDThrFlb0SQ1aLyRoEdi585Nv7Y8kW43r99JsHqj5KwYCG4e6Ucg6BJTxCPl N2dQ== X-Gm-Message-State: AOAM533ejOyeJHDomX0QR3vHA3Gver/N4qIoR8NWpZzuEr8tgN5EQMd/ xVYRJRArryu2mcg6Hj4CxvS9KshTb8TN15Fw0qmlIVVnWYJwkg== X-Google-Smtp-Source: ABdhPJyPAR/woOYU/Y+IrZ3x6CxT4j/WM8Z9wJUBpPindSeOO72mlVqceaBMYzWrRTFHTaXyahsbv1/XJayvk7AbvD0= X-Received: by 2002:a2e:90d6:: with SMTP id o22mr1121619ljg.473.1621468045994; Wed, 19 May 2021 16:47:25 -0700 (PDT) MIME-Version: 1.0 From: Bernard Aboba Date: Wed, 19 May 2021 16:47:14 -0700 Message-ID: To: IETF AVTCore WG Content-Type: multipart/alternative; boundary="000000000000e56f3205c2b7721b" Archived-At: Subject: [AVTCORE] Volunteers? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2021 23:47:33 -0000 --000000000000e56f3205c2b7721b Content-Type: text/plain; charset="UTF-8" The IETF AVTCORE WG will be having a virtual Interim on Monday, May 24, 2021 from 11 AM - 12:30 PM Pacific Time. Information on the meeting is available here: https://codimd.ietf.org/notes-ietf-interim-2021-avtcore-02-avtcore So we can save some time at the meeting, we'd like to solicit volunteers for the Note-taker and Jabber Scribe roles. Any volunteers? --000000000000e56f3205c2b7721b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The IETF AVTCORE WG will be having a virt= ual Interim on Monday, May 24, 2021=C2=A0 from 11 AM - 12:30 PM Pacific Tim= e.=C2=A0

Information=C2=A0on the meeting=C2=A0is availab= le here:=C2=A0

So we can save some time = at the meeting, we'd like to solicit volunteers for the Note-taker and = Jabber Scribe roles.=C2=A0

Any volunteers?=C2=A0

--000000000000e56f3205c2b7721b-- From nobody Thu May 20 01:50:47 2021 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8EA3A1390; Thu, 20 May 2021 01:50:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-avtcore-multi-party-rtt-mix@ietf.org, avtcore-chairs@ietf.org, avt@ietf.org, bernard.aboba@gmail.com, bernard.aboba@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.29.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <162150064568.17183.13006538345122561644@ietfa.amsl.com> Date: Thu, 20 May 2021 01:50:45 -0700 Archived-At: Subject: [AVTCORE] Robert Wilton's No Objection on draft-ietf-avtcore-multi-party-rtt-mix-18: (with COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2021 08:50:46 -0000 Robert Wilton has entered the following ballot position for draft-ietf-avtcore-multi-party-rtt-mix-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, Thanks for this document. This document is quite a long way from my core knowledge base, so I'm not sure whether there is much that I can really add. It doesn't seem to have any obvious manageability concerns. I was initially surprised by the capability exchange mechanism (offer/exchange), in that if both offeror and receiver could support multiple options then it is always the the receiver that decides which to use (by only selecting one). I think that this is probably fine. I don't know which parties generally initiate these exchanges, and whether there is ever a case where both offeror and receiver support multiple options where it would be beneficial for the offeror to make the final decision as to which should be used (e.g., when coordinating between more than two devices). As one minor nit, I would have preferred to see section 1.2, "Selected solution and considered alternatives" as an appendix. I wasn't convinced that it is core to understanding this document, but I'm happy to leave it to the authors discretion as to whether they should move it, or leave it where it is. Thanks, Rob From nobody Fri May 21 07:46:18 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789E13A12FB; Fri, 21 May 2021 07:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jacobsuniversity.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyHDKgMP3I37; Fri, 21 May 2021 07:46:12 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70057.outbound.protection.outlook.com [40.107.7.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 476F93A12F9; Fri, 21 May 2021 07:46:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Bw3z6Do77O9Eky0YQ208p9w+Esb9tgEC8O+fIl5k7+xJSY2oyqbYaAdQTnBRucwTUpXtndQugXiU1llQWAIDRy7k15Nh/wdYI5Cse3TYW5UgixILb5DXEgld46tqiyArfT6Es4Si26EJU+ruAZQ28aKgxPhCr7TSR+7SZLNDN8RdbwfdTWYucYLd8pnhAjDYcD8TJZsiqrraDN9kge12UdMhwUsgpSytRB6OdmthZIRwU2b8qFR3e7br4SXsuFR024WEx/xS6r7IH9MNAJbqSN/6WN5MdD+aE+ptXa0ZRXz5AHjPC9JMuWD4nQgYYR23ltmyxyBSVrxh347I4qLTMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TJ1O+pLoW701es+xerWRnCkoW4o+2RXDLoRtP05NcfU=; b=U6ZkOSFM+78JKiU/B9SOiRMZx0PJVtdVmXJFosiaaO96WUZB+9LGVRVokoxhSjkpbF9iAPXTyr1faqOrfC8yMwIEuFSZY3StGMJcyaB36g1+BhuTnLI5IRoO+U/1BCWdmZ1HuIPwNqw3/o+mrWmtfdUcjwlAOfLY35oo7KDoqlDlXVAyiijya+esC+RYzKQmG6ny7FRgwUk8Q/0j0q+XslmufXhqTYhWRVuCPJOMZaOPV7RkVouCpCDoI5t1OvAbohrQ9YUJ8tLwcDjfdCsEJtSezcd66rUT031gK2G5YFA6tvSuVd+tz5kWZ633duOpTojBYbGaxK1qmEvYCCkgLg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TJ1O+pLoW701es+xerWRnCkoW4o+2RXDLoRtP05NcfU=; b=TfTCcvs/4qj0ebDSjwwywteYaFgWIfvXylsknEWMdPnV3w54dyolIjQaUibTU6pfT/xiajPg/JJFYGKdI1eyFJCqywg6hKUtizLElPKWB/+7eO4cwmEqwYglcWXrXfDbI4M6UOefDXn6z7SjWFDYbrZU40258N+4XcKHDQPSIb4= Authentication-Results: ghaccess.se; dkim=none (message not signed) header.d=none;ghaccess.se; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM9P190MB1331.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:26b::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.23; Fri, 21 May 2021 14:46:09 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::fd93:9b33:ac92:ea58]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::fd93:9b33:ac92:ea58%8]) with mapi id 15.20.4150.023; Fri, 21 May 2021 14:46:09 +0000 Date: Fri, 21 May 2021 16:46:08 +0200 From: Juergen Schoenwaelder To: Gunnar =?utf-8?Q?Hellstr=C3=B6m?= Cc: ops-dir@ietf.org, last-call@ietf.org, draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org, avt@ietf.org Message-ID: <20210521144608.xp2klodaoz23oots@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Gunnar =?utf-8?Q?Hellstr=C3=B6m?= , ops-dir@ietf.org, last-call@ietf.org, draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org, avt@ietf.org References: <161951914802.5120.8507635650494768525@ietfa.amsl.com> <7a7ed2b4-bb23-48ea-d55d-c5804a2363af@ghaccess.se> Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: AM0PR02CA0228.eurprd02.prod.outlook.com (2603:10a6:20b:28f::35) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by AM0PR02CA0228.eurprd02.prod.outlook.com (2603:10a6:20b:28f::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.24 via Frontend Transport; Fri, 21 May 2021 14:46:08 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3d69805d-92d1-4e29-43c3-08d91c672ba5 X-MS-TrafficTypeDiagnostic: AM9P190MB1331: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: lp/gltCLf4kcA5npWCc0DJw187ifF0GOJ68lTcez1RfnZOgjPpCvz/i63mkmV7w4HHLcgW4H7JmmPxmdEhjIcP6POigjJbXscR6gWq3hTt7F5jRpQBRmjeZwTcN57heIx3YR9D8mKCdWwRNV9Jr5U4g3UZnsYVOPd/Bau/aiPWArLXwLfF4aAhVFIhLIA8Mp+Ha24+wub0fSgAzGePuo8MPmzTl4RRQN+7O1bip95BRyZDKPe1rkhlY9eaEr0UGkjKyh8qFaifzWKuZSJ7zoA5X6dJAvdvCjoQ42qqZjDzyKCAs7gzCqFYCIMVN4lbRhDfJGZ34mOuuigz7Zt30tRiuu1TGuqiisB+V1qmCbFQve3DCqB/5MjMneEjfqN9B9x/4tYaWQd1C0YwB1h09jD9pMUdVFt/XI07ZRxM/U+oL6Ojswqb8W5r5M4F4uEHvC93OkBdm192ffLlw9PZiDIPxZ69OZ0FgyH+OlfV6qFEmwPHR8hpiGtCeGwx0qRNANQIqyriaHgNnLNPCsDx23wL8g0j7sOmtBHvnUicK2o9rFOn9jjRxMUolBgFCqHxNBGBUiBvPXMH9ZUH0uEdhh7NXAgxDvCn2oUnNR/bhvg5XAWY4vENMq+py86VyIH7Ykxalrog0Pa2NdVU9HDMKW5pGzvQjRDhvZf9aHd5pPvxdAX28N+WvU3/6FcExNS2fsjwsf/SeuWJre3tHYmLfXrHUAS1Xa3mXj8bSGsLNuAXC/FmXdoZX2+Xa5Qb4eJBUB95zq43NFVaLOdsaktrNVtg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(346002)(136003)(39850400004)(396003)(376002)(366004)(52116002)(2906002)(16526019)(4326008)(5660300002)(66556008)(478600001)(6496006)(66946007)(1076003)(66476007)(8676002)(83380400001)(956004)(186003)(38100700002)(38350700002)(26005)(6916009)(8936002)(6486002)(786003)(966005)(316002)(3450700001)(66574015)(86362001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?iso-8859-1?Q?504sSnlGmq53+kDare7zRd0MC8QNUDFVkusk7gwreUTqWLUL6n2jHm0sWq?= =?iso-8859-1?Q?pbyIdzIdFW8JjR8W2o64f09eoTbGa3lQ3KQHr5Xdd7u3UqLE9/Ds5MI5r6?= =?iso-8859-1?Q?QTD73Iv1G/J9JfxLswWDmL5qiITniMZhbEGOgzlvZX7MBu1rmXkShjROcW?= =?iso-8859-1?Q?ATi8gzJZibARWYD/IpvfQ9zvfbeEwCt7Dl+z5hcitq5A0HYB5s1jy3ian+?= =?iso-8859-1?Q?UgirxQbTaUNY6wu+DtC31YQ6oFbkqinEd+NFZVTPcwMzyeJFTsznPK7gns?= =?iso-8859-1?Q?JloxD6szyaL5cMv3J9JfKBfACSqLfaq5vdB7SH+eQ/7hPrCBoHgOvrl7wt?= =?iso-8859-1?Q?8GeoeS6UOXthVXCc9O2ARlB4KdiiIW5DhZmTq002PcL7yK2N0O+TO+t3Wz?= =?iso-8859-1?Q?QuZWw1zg7PlmfL3pWfKGOOtmYigFE9QByjqvDFzHj01r9J0PwZmSC4dkJq?= =?iso-8859-1?Q?PVfGhQlcfyXTm0PtUxUfqrVuDxFC5rglrAZQGqlr3zCUY+Hn0ucSl5lUPo?= =?iso-8859-1?Q?aVR8oUx6PT4H5mCWLO/o+OOdIQDf1muxpPoFu6Jn2e6LylrI0ZAm4msnXq?= =?iso-8859-1?Q?IzudspB/eJV65QfMjsL3JCNSq5Q8HqbSMUAhmfkiNzM/EMa8do6BEjx0uw?= =?iso-8859-1?Q?XLM8DzEXwR9rzElLg1/pak7iBvhy0nB7dkAuDtkPFuSydOOyjGLQNxBoF0?= =?iso-8859-1?Q?qgNb3+1Tiy5JwyOF3YoZdlKarzR0rsL33le/OdH6Y5zVKaqU52YAEDh7WZ?= =?iso-8859-1?Q?ZcNArOL6MdCWa3SvNj2gR/4aZrXgpNGIZmORffsB1juNusC4BrzLWgKWhk?= =?iso-8859-1?Q?ssVMZI+IdY/vX43jSX5Av+E1oSOlZVhnxR4aBOHXEl4SgI8S6I9gOMaIJ9?= =?iso-8859-1?Q?I0vWwcgq023mCOSPb1r9EaURnAZc7ZR60NhxSRvTtMY3HxK4WHYIPJfw8P?= =?iso-8859-1?Q?nzWc/67tqxuOIW7Yj8NdFwH3biXB+i2zuuVBZHjtDwVrouN6egEr4BApZN?= =?iso-8859-1?Q?0Vsh29zsmLF+ZPnJx7XR2x3WId3GU7x7YMKZlDg7xVj7OXMRzYa3PlRKZF?= =?iso-8859-1?Q?hjBqaCILLIoAD7oVjgrb3buGpqCalrZT3K15gxIat5Yq9Tg2VLMM9vEnGZ?= =?iso-8859-1?Q?U4tNsTOOZ3A9xcX9FcWbYxp/mSl+0rEJdtCgowdZJzZi7wlvKiM5UMj/2u?= =?iso-8859-1?Q?JjaEHF12ZRvc69H1SIak+KM4BIRzYGBgIAPY/bEwj3nEIgTylW3R/Dt7Yr?= =?iso-8859-1?Q?oLg91UJPqfV4kvE5E4exh/V7ehwwNQyv/gZBTx+6p7eu/6T4mB3CAqd/JV?= =?iso-8859-1?Q?FeDeEsH4BbX3ezmzKTV7mwnEire64tr4wTOWXnLr3TDLhWTn3UBo7BV3Ri?= =?iso-8859-1?Q?8LsKPWeaA1?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 3d69805d-92d1-4e29-43c3-08d91c672ba5 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 May 2021 14:46:09.0549 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: pey+Da3ZvU3Soo59JbM0BtWBrgB0U+O9wVOFntqOhV4Mo03tur+ZkDhbzRy1tnLh0e57zJS4H2PISsGeUHPV+WjSsPiXs1HOl217a69Rrbc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1331 Archived-At: Subject: Re: [AVTCORE] Opsdir last call review of draft-ietf-avtcore-multi-party-rtt-mix-14 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2021 14:46:18 -0000 Gunnar, this looks all good to me. Thanks for considering my comments. /js On Wed, Apr 28, 2021 at 01:44:20PM +0200, Gunnar Hellstrm wrote: > Jrgen, > > I have submitted a new version, acting on your comments. > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-avtcore-multi-party-rtt-mix-15.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-multi-party-rtt-mix-15 > > > Here is a summary of what I did: > > Actions on review comments from Jurgen Schonwalder: > > A bit more about congestion situations and that they are expected to > be very rare. > > Explanation of differences in security between the conference-aware > and the conference-unaware case added in security section. > > Presentation examples with source labels made less confusing, and > explained. > > Reference to T.140 inserted at first mentioning of T.140. > > Reference to RFC 8825 inserted to explain WebRTC > > Nit in wording in terminology section adjusted. > > I hope this satisfies your comments. > > Thanks, > Gunnar > > > Den 2021-04-27 kl. 23:58, skrev Gunnar Hellstrm: > > Thank you for your review. > > > > I will provide initial reactions here, and follow up with more exact > > proposals for changes. > > > > Den 2021-04-27 kl. 12:25, skrev Jrgen Schnwlder via Datatracker: > > > Reviewer: Jrgen Schnwlder > > > Review result: Has Nits > > > > > > I am by no means an expert in this area so please take this into > > > account while reading my comments... > > > > > > Content comments: > > > > > > * The document assumes "human" communication, i.e., where text > > > originates at a speed of a human and politeness is used to resolve > > > concurrency conflicts. This seems to be a fair assumption for the > > > considered use cases but what happens if this assumption is not met? > > > Can systems or RTP mixers detect and handle such situations > > > gracefully or is the idea that any resulting "jerkiness" must be > > > accepted if senders misbehave? > > > > [GH] The receivers are expected to declare their reception speed > > capability in characters per second (over a 10 second period). A high > > capability will allow smooth flow of text from many participants > > simultaneously. The congestion section 9 tells what can be done if the > > load gets too high. The mixer can then discard text, and if it has any > > means to detect who is the main contributer, it can avid to discard text > > from that participant. (e.g. by the sdp "content" attribute. > > > > This is of course not nice. But it is equally not nice to try to hear > > any specific voice in a mixed audio channel with many participants. And > > same with video in cases when the video has real information. > > > > So we are in good company with the other media in the problem that there > > are no really good solutions to an information overload situation. > > > > In most cases the typing participants will send a sentence or two and > > then stop and read or listen to the others. In such situations the > > overload will be sorted out after a short while even without the > > participants being very polite. > > > > Do you want me to elaborate more about this in the congestion chapter 9? > > > > > > > > * The solution does not provide end-to-end security since the mixer > > > must be trusted to have access to the texts in order do the mixing. > > > This is mentioned in the security considerations and in section 2 > > > where alternatives are considered. The reason to not select a > > > solution providing end-to-end security is give in section 1.2. Is > > > there work planned to address this issue, i.e., to complement this > > > solution with a solution providing end-to-end security? > > > > [GH] There is another individual draft > > "draft-hellstrom-avtcore-multi-party-rtt-solutions", intended to > > document design choices behind the reviewed draft. It discusses the > > end-to-end security topic among other things but does not solve it. If > > there are requests for it, that work could be continued to provide > > specific solutions. But I would like to hear the request first. > > > > Maybe it is more urgent to specify how RFC 8865 "real-time text in > > WebRTC" can be used in a multi-party setting with end-to-end security. > > > > I would prefer to let the discussion of the topic in the reviewed draft > > be sufficient fo now. > > > > > > > > * Perhaps the recommendation in section 4.2.6 that the mixing method > > > for multi-party unaware endpoints is not RECOMMENDED to be used > > > should be repeated in the security considerations? It seems there > > > are serious limitations, in particular also related to the creation > > > of a presentation that can make it impossible to detect masquerade > > > attacks. Yes, masquerading is mentioned but from an outside security > > > point of view it feels like there was a strong security solution > > > that was discarded due to lack of implementation support, there is a > > > somewhat OK solution (but not able to provide end-to-end security), > > > and there is a pretty ugly solution to accommodate endpoints with no > > > support for the other solution. If this is a fair summary, perhaps > > > explaining this clearly in the security considerations would be a > > > good thing. > > [GH] Yes, good point. I will compose a proposal. > > > > > > * I am confused about Figures 5 and 6 since the mixed identities of > > > the sources are once shown in square brackets and once in > > > parenthesis. Are labels like [Alice] or [Bob] not inserted by the > > > mixer? If so, why would the format on the endpoint be different? Is > > > the idea that endpoints try to parse the mixed text in order to > > > render it differently? Or was the idea to show that different mixers > > > can use different styles to generate labels, i.e., I should not > > > really compare Figure 5 and 6? > > > > [GH] The figures should be possible to compare. And, yes, I have caused > > confusion by letting the mixer create labels with brackets in figure 5 > > but with parentheses in figure 6. In figure 6 the brackets are inserted > > by the receiving terminal in a way that has become quite common in RTT > > implementations, but the parentheses come from the mixer. Alice is the > > local user. Her text is merged locally and therefore get the label > > assigned locally. > > > > I will change so that the type of label framing is consistent and insert > > some words about the labels and their framing. > > > > > > > > Editorial comments: > > > > > > * I suggest to cite [T140] when you first refer to it in the > > > Introduction: > > > > > > OLD > > > > > > A requirement related to multi-party sessions from the presentation > > > level standard T.140 for real-time text is: "The display of text > > > from > > > > > > NEW > > > > > > A requirement related to multi-party sessions from the presentation > > > level standard T.140 [T140] for real-time text is: "The display > > > of text from > > [GH] In the previous review, I got a recommendation to delete many such > > standard names before the reference, but you are right that it would > > probably be good with using it once. > > > * as defined -> are defined and missing full stop > > > > > > OLD > > > > > > The terms SDES, CNAME, NAME, SSRC, CSRC, CSRC list, CC, RTCP, RTP- > > > mixer, RTP-translator as defined in [RFC3550] > > > > > > NEW > > > > > > The terms SDES, CNAME, NAME, SSRC, CSRC, CSRC list, CC, RTCP, RTP- > > > mixer, RTP-translator are defined in [RFC3550]. > > [GH] Yes, will do. > > > > > > * Add reference(s) to WebRTC in the terminology section? > > [GH] Yes, will do. > > > > Thanks, > > > > Gunnar > > > > > > > > > > > _______________________________________________ > > > Audio/Video Transport Core Maintenance > > > avt@ietf.org > > > https://www.ietf.org/mailman/listinfo/avt > > > -- > Gunnar Hellstrm > GHAccess > gunnar.hellstrom@ghaccess.se > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri May 21 12:42:05 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE883A1E2D for ; Fri, 21 May 2021 12:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFWXe8owGkkj for ; Fri, 21 May 2021 12:42:01 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4B4E3A1E19 for ; Fri, 21 May 2021 12:42:00 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id j10so31292037lfb.12 for ; Fri, 21 May 2021 12:42:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=PX1TUQphFk8RYgNfK4vVcU7PifmuDYkxF4e7teXsey4=; b=p9fLXdotxI2pXcRIgK4aCxqwcpXRvDrJtOBSfy5FXU7IvUFBOX7TifB9fXRJcveWgN 8ZfVi+j6EH3purRVVpuim5hacoNrUIubmBm/QFjwzLytxbEk1oJXKBSd1lOPYprIipPQ 3GvhadK/lm9xCWIdChQHJIogqTbagY1ik8az8bO7F0an7ySdBZAPqPBOPLUTBmymBxn/ uotmg+DYg3N4rK8T58+S2MpMClE15wuk3apIpj0QVv1Z3gFhnyvUdZ1/Pg2a307SGkKT 1UVUvWgPpdcUfvAbJAkCnzfBc0VUASrpvPu1N8R01WzoRM4yH2V7/7Sv4+3qyajZfEid wLXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=PX1TUQphFk8RYgNfK4vVcU7PifmuDYkxF4e7teXsey4=; b=S/n3rpWMtrQGZ9dx6vaq0UvR5CB3KvcBZUB7Vm5nhWPKR6mv5y1TaJjvDsbgPD3fTg DDMkhvaVbNBa9Mcdc/IIbijDXyrUqijkBf0H9i3dbJ4n7AZoTejy/kxjiubGzXuwnfcj 7y+xU0JZJAQAuSvLp8tkgccxr4HPHzKvnQvUpk1HWBTmJCNqLnbTRfxTqJhZjTa0p5ZS avY+iHkC/08TKmxJPySeW06kEp11DGkhqINLnTTtxVzqji7EGJYFPauBrSscAkdgKUqA uvEYYBqOcXoP+bfgy39mnNJurVlMgwvA445LMHrZGYWwnEka2yeAhBfg0SalQ1OrQIMu pXlQ== X-Gm-Message-State: AOAM532cAGR1zSIYAkGki5AjqBF5H9lngNpwYYK+qv+yRoMsArcfIhLN USwbOPXCYAb0vfHwDiwI0C5yqfCcr/mTpH6h9lpLQRVsuFM= X-Google-Smtp-Source: ABdhPJwDAvpB19i0tO7y3qWDiT7fHcL8FgtySDDeHHBCZZXtJIEM8cGbATlbBjEA47AMurzfhUerXROsi/pBjwRdiJo= X-Received: by 2002:ac2:43c6:: with SMTP id u6mr3324882lfl.145.1621626116745; Fri, 21 May 2021 12:41:56 -0700 (PDT) MIME-Version: 1.0 From: Bernard Aboba Date: Fri, 21 May 2021 12:41:46 -0700 Message-ID: To: IETF AVTCore WG Content-Type: multipart/alternative; boundary="000000000000a5ad8905c2dc40b3" Archived-At: Subject: [AVTCORE] Cancellation of Virtual Interim on May 24 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2021 19:42:03 -0000 --000000000000a5ad8905c2dc40b3 Content-Type: text/plain; charset="UTF-8" Unfortunately, it turns out that the Interim is scheduled at an inconvenient time for our main presenters, so we are cancelling it. We will go forward with developing the agenda for IETF 111. --000000000000a5ad8905c2dc40b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Unfortunately, it turns out that the Interim is scheduled = at an inconvenient time for our main presenters, so we are cancelling it.= =C2=A0

We will go forward with developing the agenda for= IETF 111.=C2=A0
--000000000000a5ad8905c2dc40b3-- From nobody Fri May 21 12:43:03 2021 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 959C63A1E30; Fri, 21 May 2021 12:43:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: avt@ietf.org, avtcore-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162162618149.12799.6793321400871134174@ietfa.amsl.com> Date: Fri, 21 May 2021 12:43:01 -0700 Archived-At: Subject: [AVTCORE] Audio/Video Transport Core Maintenance (avtcore) WG Interim Meeting Cancelled (was 2021-05-24) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2021 19:43:02 -0000 The Audio/Video Transport Core Maintenance (avtcore) virtual interim meeting for 2021-05-24 from 11:00 to 12:30 America/Los_Angeles has been cancelled. From nobody Sun May 23 13:21:51 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784773A24DE; Sun, 23 May 2021 13:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYzSbYDHuhfD; Sun, 23 May 2021 13:21:43 -0700 (PDT) Received: from smtp.egensajt.se (smtp.egensajt.se [194.68.80.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 729A53A24E0; Sun, 23 May 2021 13:21:42 -0700 (PDT) Received: from [192.168.2.137] (h77-53-37-81.cust.a3fiber.se [77.53.37.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 8DEEF20C81; Sun, 23 May 2021 22:21:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1621801298; bh=BzOE5tOfEP/lgx6YloWilQbGfb34TRl9JEPp5hizM3o=; h=Subject:From:To:Cc:References:Date:In-Reply-To:From; b=NiznL8jOx8CtLh+4SDaOFoshW4VkW2CZIpUHTR+1TcSFBxosOycURp2Gmpk4HWclI hcsKGindYBO93rtO2a5nNDB1RadiYxPA1r+GVcEn5zhMgpqysGU5rhiUWBZY/ecmuS MBKB9OlE1zbCpUUCRW4f9JLalMmbeDlK4Nm+DUPg= From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= To: Benjamin Kaduk , The IESG Cc: avtcore-chairs@ietf.org, draft-ietf-avtcore-multi-party-rtt-mix@ietf.org, avt@ietf.org References: <162139279927.706.12647899386073526674@ietfa.amsl.com> <0f0350e8-231d-8d1b-d561-a172d68ac4a3@ghaccess.se> Message-ID: <9d6ab9e2-66ab-a075-1573-7a123416f7d7@ghaccess.se> Date: Sun, 23 May 2021 22:21:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: <0f0350e8-231d-8d1b-d561-a172d68ac4a3@ghaccess.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: sv Archived-At: Subject: Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-ietf-avtcore-multi-party-rtt-mix-18: (with DISCUSS and COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 May 2021 20:21:49 -0000 Benjamin, This is a more complete answer on your DISCUSS I think the description of the procedure was too much spread out in section 3. So, I propose to delete section 3.9, and change 3.4 to become: -------------------------------------------------------------------------------------------- 3.4.  Transmission interval    A "text/red" or "text/t140" transmitter in a mixer SHALL send packets    distributed in time as long as there is something (new or redundant    T140blocks) to transmit.  The maximum transmission interval between    text from the same source SHALL then be 330 ms, when no other    limitations cause a longer interval to be temporarily used.    It is RECOMMENDED to send the next packet to a    receiver as soon as new text to that receiver is available, as long    as the maximum character rate ("CPS") to the receiver is not exceeded    during any 10-second interval.  The intention is to keep the latency    low and network load limited while keeping good protection against    text loss in bursty packet loss conditions.    The main purpose of the 330 ms interval is for timing of redundant    transmission, when no new text from the same source is available.    The reason for the value 330 ms is that many sources of text will    transmit new text with 300 ms intervals during periods of    continuous user typing, and then reception in the mixer of such new    text will cause a combined transmission of the new text and the    unsent redundancy from the previous transmission. Only when the user    stops typing, the 330 ms interval will be applied to send the    redundancy.    If the "CPS" value is reached, a longer transmission interval SHALL be    applied for text from all sources as specified in [RFC 4103] and only    as much of the text queued for transmission SHALL be sent at the end    of each transmission interval that can be allowed without exceeding    the "CPS" value. Division of text for partial transmission MUST    then be made at T140block borders.    When the transmission rate falls under the "CPS" value again,    the transmission intervals SHALL be returned to 330 ms and    transmission of new text SHALL return to be made as soon as new    text is available.    NOTE: that extending the transmission intervals during high load    periods does not change the number of characters to be conveyed.    It just evens out the load in time and reduces the number of packets    per second. With human created conversational text, the sending    user will eventually take a pause letting transmission catch up.    See also Section 8    For a transmitter not acting as a mixer, the transmission interval    principles from [RFC4103] apply, and the normal transmission interval SHALL    be 300 ms. ---------------------------------------------------------------------- Section 3.10 also needs a few changes, to read: 3.10.  Text placement in packets    The mixer SHALL compose and transmit an RTP packet to a receiver when    one of the following conditions has occurred:    *  There is unsent text available for transmission to that receiver. |   *  The current transmission interval ( normally 330 ms) has passed |     since already transmitted text was queued for |      transmission as redundant text.    At the time of transmission, the mixer SHALL populate the RTP packet    with all T140blocks queued for transmission originating from the    source in turn for transmission as long as this is not in conflict    with the allowed number of characters per second ("CPS") or the    maximum packet size.  In this way, the latency of the latest received    text is kept low even in moments of simultaneous transmission from    many sources.    Redundant text SHALL also be included, and the assessment of how much    new text can be included within the maximum packet size MUST take    into account that the redundancy has priority to be transmitted in |   its entirety.  See Section 3.4    The SSRC of the source SHALL be placed as the only member in the    CSRC-list.    Note: The CSRC-list in an RTP packet only includes the participant    whose text is included in text blocks.  It is not the same as the    total list of participants in a conference.  With audio and video    media, the CSRC-list would often contain all participants who are not    muted whereas text participants that don't type are completely silent    and thus are not represented in RTP packet CSRC-lists. ......................................................................................... The examples in section 3.21 needs some small adjustments: in packet 104, the timer should be 20 800, The text above and in packet 106 should be as you also discovered:  B1 and B2 still need to be transmitted as redundancy. |     This is planned 330 ms after packet 104. That |    would be at 21130.       |-----------------------| |     |Seq no 106, Timer=21130|       |CC=1                   |       |CSRC list B            |       | R2: B1, Offset=660    |       | R1: B2, Offset=330    |       | P:  Empty             |       |-----------------------| ----------------------------------------------------------------- Regards Gunnar . Den 2021-05-19 kl. 23:25, skrev Gunnar Hellström: > Benjamin, > > Thanks for the thorough review. > > I will respond in multiple pieces, starting with the first parts of > the DISCUSS. > > Den 2021-05-19 kl. 04:53, skrev Benjamin Kaduk via Datatracker: >> Benjamin Kaduk has entered the following ballot position for >> draft-ietf-avtcore-multi-party-rtt-mix-18: Discuss >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I'm not sure I understand how the examples are consistent with the main >> specification, so let's please discuss it to either un-confuse me or fix >> the document. >> >> Section 3.9 seems to say that the oldest (source or redundant) text at >> the mixer takes priority when there is text from more than one source >> waiting to be sent, but the examples in Section 3.21 seem to show (e.g.) >> text received from A at time 20400 that is to be sent as redundancy, >> being sent after text from B received at time 20500 (sent as primary). >> Is the intent that if there is any primary text, the oldest primary text >> is sent first, and only if there is no outstanding primary text do we >> consider the redundant text? > > [GH] You are right. The text in 3.9 i not clear enough. If there is no > new text from A, the redundancy of A shall not be sent until 330 ms > after the primary text from A was sent. > > Only if new text arrives from A before 330 ms after the previous text > was sent, then both that new text and the redundancy shall be sent, > when the new text is the oldest available. > > So in the example, it is correct to send text from B first. > > One way to say it is that redundant text shall not participate in the > age assessment until it is 330 ms older than when it was last sent. > But it shall be included if new text is available and decided to be sent. > > When composing suitable text from this, we also need to consider that > the "CPS" value may puts a limit to how much new text may be sent. > > We also have the following words last in 3.12: > > "   The T140blocks saved for transmission as redundant data are assigned >    a planned transmission time 330 ms after the current time, but SHOULD >    be transmitted earlier if new text for the same source gets in turn >    for transmission before that time." > > > So, 3.9 is about interleaving new text and not about making sure that > redundancy is sent even when there is no new text.  The text in 3.9 > may become correct by deleting the redundancy from the age assessment, > and include "CPS" consideration, to result in: > > "The source with the oldest text received in the mixer  SHALL be next > in turn to get all its available unsent text transmitted, as long as > it is allowed considering the "CPS" value of the receiver.  Any > redundant repetitions of earlier transmitted  text not yet sent the > intended number of times SHALL be included as redundant retransmission > in the transmission." > > > >> >> In a related vein, Section 3.10 says that a packet is sent when (among >> other things) "330 ms has passed since already transmitted text was >> queued for transmission as redundant text".  But that doesn't say >> anything about the timer being reset by subsequent transmission or >> queuing of redundant text, so I'm not sure how in the Section 3.21 >> example, we say that transmitting B1 and B2 as redundancy was planned as >> 330 ms after packet 105 -- the original B2 was sent in packet 104, so >> shouldn't the 330ms start from packet 104's transmission?  (The stated >> time for this seems to match 330ms after 104, so maybe the "105" is just >> a typo?) >> >> >> I also left a note in the comment that there's a remark about "lower >> security level" in Section 3.19 that's not really accurate; we should >> resolve that in some manner before the document proceeds. >> >> > [GH] > > -Answers to be continued, > > Gunnar >> >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt > -- Gunnar Hellström GHAccess gunnar.hellstrom@ghaccess.se From nobody Sun May 23 17:49:04 2021 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 147DF3A0CAE; Sun, 23 May 2021 17:49:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: avt@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: avt@ietf.org Message-ID: <162181734202.9836.1617932949380579304@ietfa.amsl.com> Date: Sun, 23 May 2021 17:49:02 -0700 Archived-At: Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rfc7983bis-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2021 00:49:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance WG of the IETF. Title : Multiplexing Scheme Updates for QUIC Authors : Bernard Aboba Gonzalo Salgueiro Colin Perkins Filename : draft-ietf-avtcore-rfc7983bis-01.txt Pages : 8 Date : 2021-05-23 Abstract: This document defines how QUIC, Datagram Transport Layer Security (DTLS), Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP), Session Traversal Utilities for NAT (STUN), Traversal Using Relays around NAT (TURN), and ZRTP packets are multiplexed on a single receiving socket. This document updates RFC 7983 and RFC 5764. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc7983bis/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rfc7983bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rfc7983bis-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 24 02:27:39 2021 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5404F3A20F7; Mon, 24 May 2021 02:27:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: avt@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: avt@ietf.org Message-ID: <162184845727.4499.18229138452091042649@ietfa.amsl.com> Date: Mon, 24 May 2021 02:27:37 -0700 Archived-At: Subject: [AVTCORE] I-D Action: draft-ietf-payload-rtp-jpegxs-14.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2021 09:27:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance WG of the IETF. Title : RTP Payload Format for ISO/IEC 21122 (JPEG XS) Authors : Sébastien Lugan Antonin Descampe Corentin Damman Thomas Richter Tim Bruylants Filename : draft-ietf-payload-rtp-jpegxs-14.txt Pages : 29 Date : 2021-05-24 Abstract: This document specifies a Real-Time Transport Protocol (RTP) payload format to be used for transporting JPEG XS (ISO/IEC 21122) encoded video. JPEG XS is a low-latency, lightweight image coding system. Compared to an uncompressed video use case, it allows higher resolutions and frame rates, while offering visually lossless quality, reduced power consumption, and end-to-end latency confined to a fraction of a frame. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-jpegxs/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-payload-rtp-jpegxs-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-jpegxs-14 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 24 02:30:33 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2163A210C; Mon, 24 May 2021 02:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=intopix.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzjbOFPMI2A7; Mon, 24 May 2021 02:30:23 -0700 (PDT) Received: from dispatchb-eu1.ppe-hosted.com (dispatchb-eu1.ppe-hosted.com [185.183.29.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 588363A2107; Mon, 24 May 2021 02:30:23 -0700 (PDT) X-Virus-Scanned: Proofpoint Essentials engine Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04lp2055.outbound.protection.outlook.com [104.47.13.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1-eu1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id E4EB17C006F; Mon, 24 May 2021 09:30:15 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ofQiJ0nNTQ3eIEjmZYb8AM7962oXBMFUxo0JE/6DB43c6EEMB3Emkd2lqHU7BCynFQpZAWwfXjeVqdS4e87M0/GR86v0a8fgrdeGOwTKo/2sw4L5ksLBawy2U1MngUgqeUjgH+5eqPU6yaJdo2feibJ1T/UGFQrs/hMBvVXDJbylhkmm1HUIiPR9H9ssP+iD1HeBa00Bxzr0m6MXv7ieblw2gKwEQceK2LS3XjaJFiQWDgmUYUX4IvDaeUg1z64hd1yUlUSGTHSQauqlrBnjxi8VzN7FNgtVhjEyadXekXDJWBttgaISMj1/KsEutskDEFrDlDB18SDKg5dN+NnE0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R1Kt1jUNKXIIJrRd9QtQyG4zn08brCplnE2VsGv5PJs=; b=JbjwTdJB6DkiSMjef5fgzVstmXT/6a/LOHEon89gcUW6aiXblP0l9fQQE9GozQX4+g1vWlkK8+fGjewZNNqhTj166nJ8eaE9VVi0t/9M5xwLJJ1U7poEgA1uPQN1CW6kCHwkXawH8/0j185eQCG8i9jLpPb+sS5KBEhg0IHgSHD+2U0P4rBaNTB886S0eAZG4dHh0k1jR+8wmnXXfr5698p70SYSycZsUz5hhnpn0N3bYcitaRby8f3ovAZsligZ/Z0iL8Zmp6qB+QGyAa60uAvaVhCnbDT8bKqZExSpQInrUqkrADHCq8oWvjztRPQaqJ6e401kK1pXmivVxvBTvg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intopix.com; dmarc=pass action=none header.from=intopix.com; dkim=pass header.d=intopix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intopix.onmicrosoft.com; s=selector1-intopix-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R1Kt1jUNKXIIJrRd9QtQyG4zn08brCplnE2VsGv5PJs=; b=R88Cd9QdDZcF20mJnVQPFf05UJ49i9dd0lQjn0+B3Ttwx7m2F5r7Q/Q5Vo+5f6gvpBbtceefRE21WGIOwfs5/HoHr6CW2mkndHiefdclgOUG/l0/ZyEdp9BzgBZjjYSnbescxRlQVcranvmDMFrxY7XBz8P7TqP8c0C2wYcWJbA= Received: from PR3P192MB0748.EURP192.PROD.OUTLOOK.COM (2603:10a6:102:4f::24) by PR3P192MB0617.EURP192.PROD.OUTLOOK.COM (2603:10a6:102:41::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.27; Mon, 24 May 2021 09:30:14 +0000 Received: from PR3P192MB0748.EURP192.PROD.OUTLOOK.COM ([fe80::8ab:c06a:c2cf:b0ac]) by PR3P192MB0748.EURP192.PROD.OUTLOOK.COM ([fe80::8ab:c06a:c2cf:b0ac%7]) with mapi id 15.20.4150.027; Mon, 24 May 2021 09:30:14 +0000 From: Tim Bruylants To: Christer Holmberg , IETF AVTCore WG CC: "avtcore-chairs@ietf.org" , "Murray S. Kucherawy" , mmusic Thread-Topic: SDP directorate review of draft-ietf-payload-rtp-jpegxs-13 Thread-Index: AddLKBOH9HzaEV4jTtmQ8TPYzmKsqwFVwo+g Date: Mon, 24 May 2021 09:30:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=intopix.com; x-originating-ip: [2a02:1810:1dbd:e901:2844:57d7:7d0d:b7a9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 221da079-a100-4682-35bb-08d91e9688e5 x-ms-traffictypediagnostic: PR3P192MB0617: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: t9FmsnGZqhM5SEI9H9rIgDvLPgHVncewojN4D7HKjzsWJrJJiKAUaVkbIAG3zgGkRqD//HJIHnvV43pTrRE6u6drgVxNLkoOm+idpXWARZ8PKQWjQNTp05tOFMbuKBOgoHpNFWwtFR+bb7R+oldKHuVr3JTAaenonjU3mWunz6Igq/L+guAiUzNiqJZNfem86z3Hg3P/jec1dyVMLEoeQCeE2vJOM/BpQrZlupwm9y+qbvq5ijfwCXdYozwUH1OxglzLCCv6SKA3OBQ06J8x3wrQEAZkqclkgD1+zVnPYT7ty1rVYRM7PeUzo783T4Xwj1v1m7YlbGrxYRJ5HTOSTqyXbhEWu/MTUyBBmbogkuINFzjtXEJ3sWZ3BbO7WxdtobBrOAsCGozdnqnocult/31llATRFrvoeCkoz9MZtNSOECWT3xGYvpB8ezVl11jBgMT+LjWFsv81nE0qVWJFRHEMNyFqtpfWhr7UNW7jcUahdP7Cj3SP6YZfL2qYT94CJzJ/sGJlkmKoWRRJamiOi8wEei6A4d1rLWUIoqeDz8TYi60BCCdCd6T5aF0uq0uRSy5zDz30KXVJR6LgWcH0Nkf1V4Vt9PB1TmnhFhxvufI= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR3P192MB0748.EURP192.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(39830400003)(376002)(136003)(396003)(366004)(346002)(83380400001)(4326008)(53546011)(5660300002)(6506007)(66946007)(55016002)(66556008)(66476007)(8676002)(38100700002)(52536014)(76116006)(66446008)(33656002)(64756008)(122000001)(9686003)(7696005)(8936002)(71200400001)(2906002)(110136005)(54906003)(478600001)(86362001)(316002)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?aDKc/z1B8gmOdWRrOXt+LLoLBFdmlcT7ZnxWOAc4s4NAzCyqxy+LGEifaV8/?= =?us-ascii?Q?pKZC68lrQjyvYilWQBTlaWHOs9Djltv/AeBBid9hnGbEEkM5xNT4SMPxyMLm?= =?us-ascii?Q?k4YVqhAxObPA9G0y11zY8WL+beRvp9r6nHZ6O1U9EutuTEqLh+NqwKcuESnm?= =?us-ascii?Q?UBZ4ZVXgfMhdqQt3ElNwDOzKuR7Hix+MgKpNJc54jdNI0trJYlRblrEOVxDf?= =?us-ascii?Q?JYYNIdDCAarIJVXa0rDZXXIfqH8z6e/eEwLdQqdkWkKgzdQ4aUcmBVtl45W4?= =?us-ascii?Q?7gQOl3oneYIwDDJFqRyP3C+X4bYnOc+1Mj9VPU5EyJk8AvfvdjnAe+FBQSER?= =?us-ascii?Q?EXQTSg+uZg1wmnoNCRwLIUIhCa0T89MWQtHVMLaKhac0YjeLbfqDb/IL+ImO?= =?us-ascii?Q?XZK5aZXLJB71Glt7eiq5dZnjzy0Zhr1bnPGNubXsxg4NF1xgCt6bkah/werf?= =?us-ascii?Q?xhbKvRlKM5tPPbPwEhP84ggIxta8hh1hlqFxCPq2BoNq1UzXhGWCTHHquBKi?= =?us-ascii?Q?/NqQ6SIFwrckxMdztDWWqPUMSrp2wqFZxOVIZ9du1SUqSftngjNgCyzBjUsw?= =?us-ascii?Q?cgV1RVt/xJ8ut+NDvywzN3ajIlSTYpBQLH/86bH/rHsFlUxvHk3deIDNZ17J?= =?us-ascii?Q?10Kgxj522ypixMACfcjdw6xWrYpUz+STMBTCeaKAGD2n6s5txgy0USAmnY4F?= =?us-ascii?Q?yKJnbaKhZq+uQbegbqISnRF17lvhH4bS9rj4B6K6adxbfNDAx/zfjHYBPHIV?= =?us-ascii?Q?YJLjJjy6IGI6Sv2aIRd2gfW62V8lE0AgbRj9POJo+ESntRit/+hTThlGGu6f?= =?us-ascii?Q?MoFEqpUABngQnM0m6kahfRKA/QHDeH7A7CRbbeQ97114JFDEWq1/N4kyrID1?= =?us-ascii?Q?1bv3HtvUTe5o2e5WTtwBiZzobrN/GcyY+ZqGR9EOuPHRzR8JZTlR7tup0MM5?= =?us-ascii?Q?gd+qrUHMxe9LMX4+0aoxqSNBBLJQKMuNnmiN7LpTgDbgw18BW/w2K2ACHKOG?= =?us-ascii?Q?tFjHkmMYIHtBGnUXjPkvlphAUTH0kETRU8+6xe/vNw5XMPiYwYpDG1dgPnOW?= =?us-ascii?Q?9b3m1CzMb8KZDVwk/ymLHpSGX9BvCWZbvQ5XJ/e2jqgw+bjiU4owMN7Q93fH?= =?us-ascii?Q?N08i9PS5YUd7Z2eAUNPNVgV7ihW7BSDzHZXgDHuwOaKWFNaRpdIELaL/6yZy?= =?us-ascii?Q?0+uMOyYnLDbEB3TwC2l9D9utNG19KzYAjYwoaCMj3ud0HoQjR0DSR2ydJm3Y?= =?us-ascii?Q?rF0lZaHbT5+n4yOmxWX/i3mhFkFwPiZGG3/4PwtphgshVrjYyGkhTD4+NWgU?= =?us-ascii?Q?0GYKeSkdQpNdzqjm4xin48rh5ZrvuyKCHWPCEqoS4TMJkJ9aYhuThOMfNMkZ?= =?us-ascii?Q?I3mRrlQt/vyPqD7jIQaplQe8NfK/?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_PR3P192MB0748357C78FECBB3CA63BE93AC269PR3P192MB0748EURP_" MIME-Version: 1.0 X-OriginatorOrg: intopix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PR3P192MB0748.EURP192.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 221da079-a100-4682-35bb-08d91e9688e5 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2021 09:30:13.9440 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5f9168c7-cdac-4b23-9509-c278399e3c1f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: anJxZOq6So68+VIe0uJNkCiXU93e7LdFe9C1F4a5aNae4dceS5A9jor1AtzMTCBl X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3P192MB0617 X-MDID: 1621848616-Nz0pXoyitR9B Archived-At: Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2021 09:30:31 -0000 --_000_PR3P192MB0748357C78FECBB3CA63BE93AC269PR3P192MB0748EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Christer, A new version of I-D, draft-ietf-payload-rtp-jpegxs-14.txt has been submitt= ed and posted to the IETF repository. We have addressed your comments and remarks as good as possible. We made the following changes to address all three questions: -> (Q1) We have moved Section 7.2 to become a separate main section (now se= ction 8). -> (Q2) We removed the sentence. -> (Q2 and Q3) We reworked both subsections and tried to clarify better wha= t was intended to be expressed. As such, the intent of the SDP Offer/Answer negotiation is that a receiver = can offer a certain set of parameters (and values) that it wants to receive= . The answerer (or sender in this case) can either honor this offer exactly= (i.e. everything in the offer can be matched inside the payload) or drop t= he offered SDP media description. As an example, when the receiver wants 4:= 2:0 content, it can signal this in the offer by specifying the "sampling" p= arameter with a value of "YCbCr-4:2:0". The sender is not allowed to answer= with another sampling format (to counter offer). On the other hand, if the offerer does not specify a specific optional para= meter (meaning it does not care about this specific feature), the answerer = is allowed to clarify in the answer such optional parameter. For example, a= n offer is made without specifying the frame rate, the answer is allowed to= add the "exactframerate" option with a value that matches the payload. Thi= s is true for any unspecified optional parameter in the offer. We hope this addresses all concerns regarding SDP. Best regards, Tim Bruylants. From: avt On Behalf Of Christer Holmberg Sent: Monday 17 May 2021 16:24 To: IETF AVTCore WG Cc: avtcore-chairs@ietf.org; Murray S. Kucherawy ; mmu= sic Subject: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-= 13 Hi, I have performed the SDP directorate review of draft-ietf-payload-rtp-jpegx= s-13. Regards, Christer ---- Q.1 I suggest converting section 7.2 to a separate main section, and change the= name to "SDP Offer/Answer Considerations". I don't think we need to consid= er other SDP usage than Offer/Answer. Q.2. Regarding section 7.2.1.: "A Session Description Protocol (SDP) [RFC8866] media description SHALL= be created for each RTP stream." This sentence is not needed. "The information carried in the media type specification of Section 7.1 has a specific mapping to the SDP fields, used to describe RTP sessions. This information is redundant with the information found in the payload data (namely, in the JPEG XS header segment) and SHALL be consistent with it." In SDP offer/answer, you typically indicate what you are willing to RECEIVE= . In this case it seems like you indicate what you are going to SEND. Is th= ere a reason for that? I guess that impacts Section 7.2.3 too. Q.3. Regarding Section 7.2.3.: "All parameters must be supported by both sides," In Section 7.2.1 you say that the receiver shall ignore unrecognized parame= ters. I ASSUME that you mean that the all the parameter defined in Section = 7.2.1. "i.e. the answerer SHALL either maintain all parameters or remove the= media format (payload type) completely if one or more of the parameter values are not supported." I don't understand what this mean. According to Section 7.2.1, some of the = parameters are OPTIONAL. Is the answerer only allowed to reply with paramet= ers that were present in the offer? --_000_PR3P192MB0748357C78FECBB3CA63BE93AC269PR3P192MB0748EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Christer,

 

A new version of I-D, draft-ietf-payload-rtp-jpeg= xs-14.txt has been submitted and posted to the IETF repository.<= /p>

 

We have addressed your comments and remarks as go= od as possible.

 

We made the following changes to address all thre= e questions:

 

-> (Q1) We have moved Section 7.2 to become a = separate main section (now section 8).

-> (Q2) We removed the sentence.

-> (Q2 and Q3) We reworked both subsections an= d tried to clarify better what was intended to be expressed.

 

As such, the intent of the SDP Offer/Answer negot= iation is that a receiver can offer a certain set of parameters (and values= ) that it wants to receive. The answerer (or sender in this case) can eithe= r honor this offer exactly (i.e. everything in the offer can be matched inside the payload) or drop the offered SDP me= dia description. As an example, when the receiver wants 4:2:0 content, it c= an signal this in the offer by specifying the "sampling" paramete= r with a value of "YCbCr-4:2:0". The sender is not allowed to answer with another sampling format (to counter offer).<= o:p>

 

On the other hand, if the offerer does not specif= y a specific optional parameter (meaning it does not care about this specif= ic feature), the answerer is allowed to clarify in the answer such optional= parameter. For example, an offer is made without specifying the frame rate, the answer is allowed to add th= e "exactframerate" option with a value that matches the payload. = This is true for any unspecified optional parameter in the offer.

 

 

We hope this addresses all concerns regarding SDP.

 

Best regards,

Tim Bruylants.

 

 

From: avt <avt-bounces@ietf.org> On = Behalf Of Christer Holmberg
Sent: Monday 17 May 2021 16:24
To: IETF AVTCore WG <avt@ietf.org>
Cc: avtcore-chairs@ietf.org; Murray S. Kucherawy <superuser@gmail= .com>; mmusic <mmusic@ietf.org>
Subject: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-= jpegxs-13

 

Hi,

 

I have performed the SDP directorate review of draft= -ietf-payload-rtp-jpegxs-13.

 

Regards,

 

Christer

 

----

 

Q.1

 

I suggest converting section 7.2 to a separate main = section, and change the name to "SDP Offer/Answer Considerations"= . I don't think we need to consider other SDP usage than Offer/Answer.=

 

 

Q.2. Regarding section 7.2.1.:

 

 

    "A Session Description Proto= col (SDP) [RFC8866] media description SHALL be created for each RTP stream.= "

 

This sentence is not needed.

 

 

     "The information carri= ed in the media type specification of

      Section 7.1 has a spe= cific mapping to the SDP fields, used to

      describe RTP sessions= .  This information is redundant with the

      information found in = the payload data (namely, in the JPEG XS header

      segment) and SHALL be= consistent with it."

 

In SDP offer/answer, you typically indicate what you= are willing to RECEIVE. In this case it seems like you indicate what you a= re going to SEND. Is there a reason for that? I guess that impacts Section = 7.2.3 too.

 

 

Q.3. Regarding Section 7.2.3.:

 

     "All parameters must b= e supported by both sides,"

 

In Section 7.2.1 you say that the receiver shall ign= ore unrecognized parameters. I ASSUME that you mean that the all the parame= ter defined in Section 7.2.1.

 

      "i.e. the answer= er SHALL either maintain all parameters or remove the media format (payload=

       type) completel= y if one or more of the parameter values are not

       supported."= ;

 

I don't understand what this mean. According to Sect= ion 7.2.1, some of the parameters are OPTIONAL. Is the answerer only allowe= d to reply with parameters that were present in the offer?

--_000_PR3P192MB0748357C78FECBB3CA63BE93AC269PR3P192MB0748EURP_-- From nobody Mon May 24 07:33:36 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABF73A2AD2; Mon, 24 May 2021 07:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7KqDPMdeJM3; Mon, 24 May 2021 07:33:29 -0700 (PDT) Received: from smtp.egensajt.se (smtp.egensajt.se [193.42.159.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 319763A2AAC; Mon, 24 May 2021 07:33:28 -0700 (PDT) Received: from [192.168.2.137] (h77-53-37-81.cust.a3fiber.se [77.53.37.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 3F15D2004C; Mon, 24 May 2021 16:33:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1621866805; bh=uiy5phX1K8yoBjcJFJHxPh0F4Jm3+Pk2+E/CCyvbsOU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=PrI9dXz4xUko12t7cOM0wVsI2zGuHHQrvl11QgKtJDgVsrWL8uePCQajPvG2mz4cm aFOHAVByqQkystis9hs6EH1Ghq98RB3a4YEGjTiiJp3aLc2e4UZppLken1MQdyZAXs qmlSWOwu4Wd4KxzFNMZmidl51Qz30u899UXk6sjo= To: Benjamin Kaduk , The IESG Cc: draft-ietf-avtcore-multi-party-rtt-mix@ietf.org, avtcore-chairs@ietf.org, avt@ietf.org, bernard.aboba@gmail.com References: <162139279927.706.12647899386073526674@ietfa.amsl.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Mon, 24 May 2021 16:33:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: <162139279927.706.12647899386073526674@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------BCCC6E69C69AD0C803FA198E" Content-Language: sv Archived-At: Subject: Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-ietf-avtcore-multi-party-rtt-mix-18: Answer 2 on 3.19 security X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2021 14:33:35 -0000 This is a multi-part message in MIME format. --------------BCCC6E69C69AD0C803FA198E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Benjamin, I hope I resolved the issues with 3.9 in the previous answer. Therefore I continue here with 3.19 that you partly included in the DISCUSS. You say: "I also left a note in the comment that there's a remark about "lower security level" in Section 3.19 that's not really accurate; we should resolve that in some manner before the document proceeds." Section 3.19 Security SHOULD be applied when possible regarding the capabilities of the participating devices by use of SIP over TLS by default "Security" is not some all-encompassing attribute that can be generically applied; there are specific security properties that may or may not be achieved by any given mechanism, and it's generally worth being precise about what properties are (or are not) achieved. So here we might say "security mechanisms to provide confidentiality and integrity protection and peer authentication SHOULD be applied". [GH] Accepted and included.  We cannot in general achieve source authenticity with just SRTP when a mixer is involved, though RFC 8723 does specify a double-encryption mechanism that applies in some cases when there is a central media distributor.  In applications where legacy endpoints without security may exist, a negotiation SHOULD be performed to decide if encryption on the media level will be applied. [...] How would endpoints know if legacy endpoints might exist? [GH] It may be a decision by the service provider. It is of course not desirable to mix secure and unsecured endpoints, but that is what is specified in the next generation emergency service RFC:s RFC 6443 and RFC 6881. These RFCs have reasoning about that choise. I suggest to replace "may exist" with "are allowed".  How would this negotiation be performed? [GH]The draft only supplies a suitable example in next sentence by recommending RFC 8643 OSRTP when nothing else is specified in the application. RFC 6443 and RFC 6881 also specifies mechanisms to be used for negotiating security. I suggest that that is sufficient.  security levels. The mixing for conference-unaware endpoints has lower security level than the mixing method for conference-aware endpoints, because there may be an opportunity for a malicious mixer or a middleman to masquerade the source labels accompanying the text streams in text format. This is especially true if support of un- encrypted SIP and media is supported because of lack of such support in the target endpoints. However, the mixing for conference-aware endpoints as specified here also requires that the mixer can be trusted. [...] As the last sentence indicates, the provided reasoning in the first sentence is not really accurate, since the mixer could just as easily adjust the CSRC value in the header as change the label in the in-band text stream. This does not inherently invalidate the claim that there are different security levels, though, as the correct behavior of the mixer seems easier to independently validate in the conference-aware endpoint case (with the well-formed RTP payloads providing information that can be validated out-of-band with other participants). But I don't think this description should be left in the document as-is; it doesn't seem accurate. In the case of unencrypted media, it does seem technically true that it is easier for a non-mixer middleman to masquerade the source labels, since in that case it only adjusts the payload directly without needing to keep state on the RTP sender information and produce well-formed RTP headers after its adjustment. But this is only a modest level of additional difficulty and does not reflect any kind of effective security control, so it may not be worth mentioning at all. [GH]I suggest to delete the paragraph, except the last sentence referring to "Further security considerations..."  End-to-end encryption would require further work and could be based on WebRTC as specified in Section 1.2. Is RFC 8723 not applicable to these scenarios at all? I do not think it is WebRTC-specific. [GH] Yes, it looks good, but requires quite another approach to how to detect and indicate text loss, because RFC 2198 that is used, has a header in the RTP payload, containing Payload type and timestamp offsets. RFC 8723 has a special chapter on how to handle cases when RFC 2198 is used, and it requires the detection of loss and recovery to be handled between the source and the destination rather than by the mixer. I suggest to add reference to RFC 8723 in the sentence about further work to read: "End-to-end encryption would require further work and could be based on WebRTC as specified in section 1.2 or on double encryption as specified in [RFC8723]." ---- Continuation will follow with the COMMENT points. Thanks, Gunnar Den 2021-05-19 kl. 04:53, skrev Benjamin Kaduk via Datatracker: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-avtcore-multi-party-rtt-mix-18: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I'm not sure I understand how the examples are consistent with the main > specification, so let's please discuss it to either un-confuse me or fix > the document. > > Section 3.9 seems to say that the oldest (source or redundant) text at > the mixer takes priority when there is text from more than one source > waiting to be sent, but the examples in Section 3.21 seem to show (e.g.) > text received from A at time 20400 that is to be sent as redundancy, > being sent after text from B received at time 20500 (sent as primary). > Is the intent that if there is any primary text, the oldest primary text > is sent first, and only if there is no outstanding primary text do we > consider the redundant text? > > In a related vein, Section 3.10 says that a packet is sent when (among > other things) "330 ms has passed since already transmitted text was > queued for transmission as redundant text". But that doesn't say > anything about the timer being reset by subsequent transmission or > queuing of redundant text, so I'm not sure how in the Section 3.21 > example, we say that transmitting B1 and B2 as redundancy was planned as > 330 ms after packet 105 -- the original B2 was sent in packet 104, so > shouldn't the 330ms start from packet 104's transmission? (The stated > time for this seems to match 330ms after 104, so maybe the "105" is just > a typo?) > > > I also left a note in the comment that there's a remark about "lower > security level" in Section 3.19 that's not really accurate; we should > resolve that in some manner before the document proceeds. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > -- Gunnar Hellström GHAccess gunnar.hellstrom@ghaccess.se --------------BCCC6E69C69AD0C803FA198E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Benjamin,

I hope I resolved the issues with 3.9 in the previous answer.

Therefore I continue here with 3.19 that you partly included in the DISCUSS.

You say: 

"I also left a note in the comment that there's a remark about "lower
security level" in Section 3.19 that's not really accurate; we should
resolve that in some manner before the document proceeds."
Section 3.19

   Security SHOULD be applied when possible regarding the capabilities
   of the participating devices by use of SIP over TLS by default

"Security" is not some all-encompassing attribute that can be
generically applied; there are specific security properties that may or
may not be achieved by any given mechanism, and it's generally worth
being precise about what properties are (or are not) achieved.  So here
we might say "security mechanisms to provide confidentiality and
integrity protection and peer authentication SHOULD be applied". 

[GH] Accepted and included.

 We
cannot in general achieve source authenticity with just SRTP when a
mixer is involved, though RFC 8723 does specify a double-encryption
mechanism that applies in some cases when there is a central media
distributor.
 


 In
   applications where legacy endpoints without security may exist, a
   negotiation SHOULD be performed to decide if encryption on the media
   level will be applied.  [...]

How would endpoints know if legacy endpoints might exist?

[GH] It may be a decision by the service provider. It is of course not desirable to mix secure and unsecured endpoints, but that is what is specified in the next generation emergency service RFC:s RFC 6443 and RFC 6881. These RFCs have reasoning about that choise. 
I suggest to replace "may exist" with "are allowed".  


 How would this negotiation be performed?
[GH]The draft only supplies a suitable example in next sentence by recommending RFC 8643 OSRTP when nothing else is specified in the application. RFC 6443 and RFC 6881 also specifies mechanisms to be used for negotiating security. I suggest that that is sufficient.  



 security levels.  The mixing for conference-unaware endpoints has
   lower security level than the mixing method for conference-aware
   endpoints, because there may be an opportunity for a malicious mixer
   or a middleman to masquerade the source labels accompanying the text
   streams in text format.  This is especially true if support of un-
   encrypted SIP and media is supported because of lack of such support
   in the target endpoints.  However, the mixing for conference-aware
   endpoints as specified here also requires that the mixer can be
   trusted.  [...]

As the last sentence indicates, the provided reasoning in the first
sentence is not really accurate, since the mixer could just as easily
adjust the CSRC value in the header as change the label in the in-band
text stream.  This does not inherently invalidate the claim that there
are different security levels, though, as the correct behavior of the
mixer seems easier to independently validate in the conference-aware
endpoint case (with the well-formed RTP payloads providing information
that can be validated out-of-band with other participants).  But I don't
think this description should be left in the document as-is; it doesn't
seem accurate.

In the case of unencrypted media, it does seem technically true that it
is easier for a non-mixer middleman to masquerade the source labels,
since in that case it only adjusts the payload directly without needing
to keep state on the RTP sender information and produce well-formed RTP
headers after its adjustment.  But this is only a modest level of
additional difficulty and does not reflect any kind of effective
security control, so it may not be worth mentioning at all.
[GH]I suggest to delete the paragraph, except the last sentence referring to "Further security considerations..."

 End-to-end encryption would require further work and could be based
   on WebRTC as specified in Section 1.2.

Is RFC 8723 not applicable to these scenarios at all?  I do not think it
is WebRTC-specific.
[GH] Yes, it looks good, but requires quite another approach to how to detect and indicate text loss, because RFC 2198 that is used, has a header in the RTP payload, containing Payload type and timestamp offsets. RFC 8723 has a special chapter on how to handle cases when RFC 2198 is used, and it requires the detection of loss and recovery to be handled between the source and the destination rather than by the mixer. I suggest to add reference to RFC 8723 in the sentence about further work to read: "End-to-end encryption would require further work and could be based on WebRTC as specified in section 1.2 or on double encryption as specified in [RFC8723]."

----

Continuation will follow with the COMMENT points.
Thanks,

Gunnar
Den 2021-05-19 kl. 04:53, skrev Benjamin Kaduk via Datatracker:
Benjamin Kaduk has entered the following ballot position for
draft-ietf-avtcore-multi-party-rtt-mix-18: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm not sure I understand how the examples are consistent with the main
specification, so let's please discuss it to either un-confuse me or fix
the document.

Section 3.9 seems to say that the oldest (source or redundant) text at
the mixer takes priority when there is text from more than one source
waiting to be sent, but the examples in Section 3.21 seem to show (e.g.)
text received from A at time 20400 that is to be sent as redundancy,
being sent after text from B received at time 20500 (sent as primary).
Is the intent that if there is any primary text, the oldest primary text
is sent first, and only if there is no outstanding primary text do we
consider the redundant text?

In a related vein, Section 3.10 says that a packet is sent when (among
other things) "330 ms has passed since already transmitted text was
queued for transmission as redundant text".  But that doesn't say
anything about the timer being reset by subsequent transmission or
queuing of redundant text, so I'm not sure how in the Section 3.21
example, we say that transmitting B1 and B2 as redundancy was planned as
330 ms after packet 105 -- the original B2 was sent in packet 104, so
shouldn't the 330ms start from packet 104's transmission?  (The stated
time for this seems to match 330ms after 104, so maybe the "105" is just
a typo?)


I also left a note in the comment that there's a remark about "lower
security level" in Section 3.19 that's not really accurate; we should
resolve that in some manner before the document proceeds.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se
--------------BCCC6E69C69AD0C803FA198E-- From nobody Mon May 24 14:02:30 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33AF53A08C2; Mon, 24 May 2021 14:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZ7aqzCHRAqK; Mon, 24 May 2021 14:02:23 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150042.outbound.protection.outlook.com [40.107.15.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4BFB3A08C0; Mon, 24 May 2021 14:02:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XpB3CLmNbEqS10inmYKwCVYfGHC76XEnb+SWAHdADiqQvOJ16Oyo+kkwe/Cz3z6zp/dqs7Wdmy1wcawK8SoijeOT+YM2zfJtxnv1KUap82jT0ozvkOjk0/oQB1V3a97dEE0W8qP4t3UTVoP6JK/QLCdn9lZa9+f1/VNrir1iOwQr/H5tNVjlZADmWW2KFEViG5rnqqxSVkK+DbQBLx4lL1mpulhH5TvUbgHnKkjEEyKLm+arkXPvoNeI88Sqqe4CoTDE9ARd3v+esk4Zv73IEZ3OMQWoxky04vR4zYCBHXm2nLSX+oQjBEYGlJrbX7fKP8WtkcxOQxkhIiUEwVcOuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LokajZFw1A9DiJSnXTmKX3endNvm+H12Re1jhLrNY8c=; b=aKjLuzl7hWtoB2p5ARUTyS955D5NrP9N72vPwaZxqGDL6Yk+U8pTiJkmkHiPmPE3Lh2WxcxOTx9YsKIWZhsjIPLsA6Gsp3IB45u24L7eQh9Grd7767gQpnm7NqQsXQVe94Sr/2lyfcw/x+flCvAZDJGKfWrTgb2CH/TttJGR6OB9Sn3lmB5P+iMrfszr5jCMTTOo0PE/VcPmuRQq9d1bMlpLTz/cvj662t+YCgzrLb31RH11R0uS6XLtnO77opx737Baif+4CQmOkKQpFIYRavXh+GugPVSY6thvBry3t7x2HAAVhHNmYMYWxq+8Y6lPKffsOfBx74Crqxf1ezM+ZA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LokajZFw1A9DiJSnXTmKX3endNvm+H12Re1jhLrNY8c=; b=hcjlwO1EhjWNgKC7hf/ux57p7Hq4xMTVFyFVmxVM8VTEdGX6o+IeAOKIlvSqLblJllP8txffiO++I4DUAaJ45WLYjaDA+frY8mbKILjWiI5PBvG1a4PcbN/cBOLCBTxyNsGVXoof2WNhln5o9Mi14FlHkE/avTo+LxYborK64+w= Received: from AM0PR07MB3860.eurprd07.prod.outlook.com (2603:10a6:208:4c::18) by AM0PR07MB4817.eurprd07.prod.outlook.com (2603:10a6:208:f7::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.11; Mon, 24 May 2021 21:02:18 +0000 Received: from AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::b10f:ebc0:80d:db2]) by AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::b10f:ebc0:80d:db2%7]) with mapi id 15.20.4173.018; Mon, 24 May 2021 21:02:18 +0000 From: Christer Holmberg To: Tim Bruylants , IETF AVTCore WG CC: "avtcore-chairs@ietf.org" , "Murray S. Kucherawy" , mmusic Thread-Topic: SDP directorate review of draft-ietf-payload-rtp-jpegxs-13 Thread-Index: AddLKBOH9HzaEV4jTtmQ8TPYzmKsqwFVwo+gABfRKwA= Date: Mon, 24 May 2021 21:02:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: intopix.com; dkim=none (message not signed) header.d=none;intopix.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [80.248.247.159] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fa16bd56-4bd6-4f94-3b54-08d91ef73786 x-ms-traffictypediagnostic: AM0PR07MB4817: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /15WQ4V0X4c44F5c53pmtIybLCYeACH/VHCxePUdXge1YDVFCYjhhfuH8HymFsQz9F7mbcrD8XrqvvT3slLXb3aT/JrTa8tbLgq2p0UlZ9YEYG4OXcypbFNIkalyAoiB3eqtpR2CTzvWmh2NBxMolWlrY+Z/PY7jqA72hOwbeqwBeEv3P7Fx+ruX5gQ2+9E+E/+fsdGBPUi/tfDbF2fcvIDRfrfpieOhMYQ6lpfw7ZCnSbvvv5jdyfnI9w8DrohSPwK/Huwf0c2XFZZWvg6sr4njG0RwrsGVa8NiyfQ8MckodJ9SFQILS0yEQiRZ1L1VbCVhq3TcVJjtEBkAzPi6naScdiBdXRDw14uAEvArvzUuapDeQNZ0ZY9HIWP9W/NOSSXA1lr9t5VeiCiTNVYwSEQD+61a02NKQb3xE5Dtdymm8vUoziSDtbAjdBV6EOYoe19Ztwri2SvP3OPfmEOtBGaPz74CujVrH06E8SCjVy/EnTta5FjyHzNXdnIurfVJgEG04GMuzDwVjmrJnA8y0MmoQldiCITDgVQHJAclv1+3UuxCgoGXfw8/eoJVd9YHW+w0JUEUmcxeMbM6VNgYwPZj58hZ+abRtHX/BujeuNg= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3860.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(39860400002)(366004)(346002)(136003)(376002)(26005)(186003)(8936002)(44832011)(6506007)(53546011)(8676002)(9686003)(86362001)(66476007)(66446008)(2906002)(71200400001)(38100700002)(122000001)(4326008)(66946007)(478600001)(7696005)(5660300002)(316002)(33656002)(52536014)(66556008)(54906003)(55016002)(110136005)(64756008)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?7CGuq3rCqJJHx+bnimYYjxtDnNgY3OlLC17ekGaaVCwSWgZRpWeqM0BXOtbS?= =?us-ascii?Q?ETaNimQY7QX81yboeEGN450P0E4VrZy/LsoowUOHyIg37Yz+g3vM8iU5sAMf?= =?us-ascii?Q?MaKa1b7rwyqxqUzABxlHfYz1y+SOlVCy7IElzj1sLzfUj8CgrOAAQfxT5CZl?= =?us-ascii?Q?so7nzHl9d8Ve2b+tWW+VVl5JffDqx+VVGV8cTcAmiBIeBnBgoxa0XfuipMHK?= =?us-ascii?Q?vlxbsEOR1GGexX2EYwmdBjSakY5znZGrRu0bMVeQv+kuki4Z+C1P0aub7jQI?= =?us-ascii?Q?5MibmjZh8IVUwwWJ48lCLlKtkVafHEunmZu692BPJFThMk9eWO7es++DtQdk?= =?us-ascii?Q?KIe+ntFiD9wdZtxUlxIZZwZlvCltPXy+4DrJzZ9vsFWp3azUYOKPWHy1UMpd?= =?us-ascii?Q?yX1mDTHLmMOmnMxKvGHC6fj8K4E8jrIPLktVXE9y8oj7HaC9HJ3G7+U8If8k?= =?us-ascii?Q?bcQPhGl01TH4HQWefGFnffxg9ZBk6jBhCxT1hELT/eDaVBGyva4dmh65YwuH?= =?us-ascii?Q?8EQUUuvnNcqDFLPno0L+x1h7sP1U4Us3UTYsVLyVrTBqVdJAIhDPW3JrFAmy?= =?us-ascii?Q?KIJwToftbJyhCiKuP52tfeG0r+GMnM1yelrXSoq60Waw7snPoL3FHDT1FXTy?= =?us-ascii?Q?YskfDWO1MCqQQ0Pcphgh+MkaK2165xPk+RaTauyZDIq3Z4DVE9HqOA3X+0cn?= =?us-ascii?Q?1C9/Xbeyf50plYU9oayujgPVU9Yy31fGEJKNiy9M7wTHqKPPoWuvD7MDLfsM?= =?us-ascii?Q?IfOX0CoISFUIUGeQuDhiM3Z4XkxyfTE+X7mSK+5cyee1s0Mgcz1W+avBvdCS?= =?us-ascii?Q?mHGNdVy7UfwcnQuzB3rgg1xK2Qj6eihLsV+JHFob7f8UYc7PusZXxPPRsBlx?= =?us-ascii?Q?y1KQD6j8YyJY7BHoGiV9oRZwlds2RZ3/MKjEo8J37YMgimP5geShEzHx7nxu?= =?us-ascii?Q?Xu1V1Zkn8xlCH868Tzeu66n3GM1yrv5E2RM9dRYKlkoBoNBgmeaQOJ8NGd+P?= =?us-ascii?Q?10e2PKoc+b2dQMBr9QhSR/EaQZU/jLIW7Ka+8/px0HItxp1CPoKCBA5KfDMG?= =?us-ascii?Q?GEoOI+26OVpsY12xVR5y5hQflzpqJ7J6eTRHyp6BcUm5Ft62T0y2eb59aA1x?= =?us-ascii?Q?srS1Obw3mhN0hbSwRMs+ZdptibsX2dzO7ypoLknbcoivV1MgmW3NKusxsfEE?= =?us-ascii?Q?QA4CwIAgHQoaYeK0IhdVarPtAzi6De4J2hkjuUUD6W9i591xEX3XZHhKB2u6?= =?us-ascii?Q?DznHtrjktZnKARVFZG0OK7tZ1hn0nTMD0xolO4pdWVRdGW/YeanggYeRSc4b?= =?us-ascii?Q?G+Rg0/D7LnvhtDeGqfTMMiD4?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR07MB38607E9DDEB4FC8B86FC3FBB93269AM0PR07MB3860eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB3860.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fa16bd56-4bd6-4f94-3b54-08d91ef73786 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2021 21:02:18.5825 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 0BJVrSZkqJzLnI/+6WLq6LJrgmhEHht0i0fsuqMZMzQcgQcMhLHa7TJLWGFTN906UREH7CB2w6CUXysvCzhzarG+H+i1B3l7/yam8tN7HbU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4817 Archived-At: Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2021 21:02:28 -0000 --_000_AM0PR07MB38607E9DDEB4FC8B86FC3FBB93269AM0PR07MB3860eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, >A new version of I-D, draft-ietf-payload-rtp-jpegxs-14.txt has been submit= ted and posted to the IETF repository. > >We have addressed your comments and remarks as good as possible. > >We made the following changes to address all three questions: > >-> (Q1) We have moved Section 7.2 to become a separate main section (now s= ection 8). >-> (Q2) We removed the sentence. >-> (Q2 and Q3) We reworked both subsections and tried to clarify better wh= at was intended to be expressed. > >As such, the intent of the SDP Offer/Answer negotiation is that a receiver= can offer a certain set of parameters (and values) that it wants to receiv= e. The answerer (or sender in this case) >can either honor this offer exactly (i.e. everything in the offer can be m= atched inside the payload) or drop the offered SDP media description. As an= example, when the receiver wants >4:2:0 content, it can signal this in the offer by specifying the "sampling= " parameter with a value of "YCbCr-4:2:0". The sender is not allowed to ans= wer with another sampling format (to counter offer). > >On the other hand, if the offerer does not specify a specific optional par= ameter (meaning it does not care about this specific feature), the answerer= is allowed to clarify in the answer such optional parameter. >For example, an offer is made without specifying the frame rate, the answe= r is allowed to add the "exactframerate" option with a value that matches t= he payload. This is true for any unspecified optional parameter in the offe= r. Unfortunately I don't think what you explain above is very clear in the tex= t. Consider the following. The offerer sends an offer. The offerer specifies the characteristics that = the offerer wants to receive. Similarly, the answer specifies the character= istics that the answerer wants to receive - the answerer does NOT specify w= hat it is going to send. which I think the text is currently describing. So, I think you need to describe that the offerer indicates what it wants t= o receive. Then, you need to specify that, if the answerer accepts the offered paramet= ers, it sends an answer, in which it indicates what it wants to receive. It= is fine to say that the answerer must indicate the same characteristics as= the offerer, if that is required. "The receiver SHALL ignore any unrecognized parameter or invalid parameter = value." First, In my opinion invalid parameters values shall trigger an error. Second, what is an unrecognized parameter? Also, the text does not say what restrictions (if any) there are when it co= mes to modify the stream during a session. Is it allowed to modify any/all = characteristics? Regards, Christer From: avt > On Behalf Of = Christer Holmberg Sent: Monday 17 May 2021 16:24 To: IETF AVTCore WG > Cc: avtcore-chairs@ietf.org; Murray S. Kuch= erawy >; mmusic > Subject: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-= 13 Hi, I have performed the SDP directorate review of draft-ietf-payload-rtp-jpegx= s-13. Regards, Christer ---- Q.1 I suggest converting section 7.2 to a separate main section, and change the= name to "SDP Offer/Answer Considerations". I don't think we need to consid= er other SDP usage than Offer/Answer. Q.2. Regarding section 7.2.1.: "A Session Description Protocol (SDP) [RFC8866] media description SHALL= be created for each RTP stream." This sentence is not needed. "The information carried in the media type specification of Section 7.1 has a specific mapping to the SDP fields, used to describe RTP sessions. This information is redundant with the information found in the payload data (namely, in the JPEG XS header segment) and SHALL be consistent with it." In SDP offer/answer, you typically indicate what you are willing to RECEIVE= . In this case it seems like you indicate what you are going to SEND. Is th= ere a reason for that? I guess that impacts Section 7.2.3 too. Q.3. Regarding Section 7.2.3.: "All parameters must be supported by both sides," In Section 7.2.1 you say that the receiver shall ignore unrecognized parame= ters. I ASSUME that you mean that the all the parameter defined in Section = 7.2.1. "i.e. the answerer SHALL either maintain all parameters or remove the= media format (payload type) completely if one or more of the parameter values are not supported." I don't understand what this mean. According to Section 7.2.1, some of the = parameters are OPTIONAL. Is the answerer only allowed to reply with paramet= ers that were present in the offer? --_000_AM0PR07MB38607E9DDEB4FC8B86FC3FBB93269AM0PR07MB3860eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /o:p>

 

>A new version of I-D, dr= aft-ietf-payload-rtp-jpegxs-14.txt has been submitted and posted to the IET= F repository.

> =

>We have addressed your c= omments and remarks as good as possible.

> =

>We made the following ch= anges to address all three questions:

> =

>-> (Q1) We have moved= Section 7.2 to become a separate main section (now section 8).<= /span>

>-> (Q2) We removed th= e sentence.

>-> (Q2 and Q3) We rew= orked both subsections and tried to clarify better what was intended to be = expressed.

> =

>As such, the intent of t= he SDP Offer/Answer negotiation is that a receiver can offer a certain set = of parameters (and values) that it wants to receive. The answerer (or sende= r in this case)

>can either honor this offer exactly (i.e. everything in the offer can b= e matched inside the payload) or drop the offered SDP media description. As= an example, when the receiver wants

>4:2:0 content, it can signal this in the offer by specifying the "= sampling" parameter with a value of "YCbCr-4:2:0". The sende= r is not allowed to answer with another sampling format (to counter offer).

> =

>On the other hand, if th= e offerer does not specify a specific optional parameter (meaning it does n= ot care about this specific feature), the answerer is allowed to clarify in= the answer such optional parameter.

>For example, an offer is made without specifying the frame rate, the an= swer is allowed to add the "exactframerate" option with a value t= hat matches the payload. This is true for any unspecified optional parameter in the offer.

 

Unfortunately I don’t = think what you explain above is very clear in the text.

 

Consider the following.=

 

The offerer sends an offer. = The offerer specifies the characteristics that the offerer wants to receive= . Similarly, the answer specifies the characteristics that the answerer wan= ts to receive – the answerer does NOT specify what it is going to send. which I think the text is currently desc= ribing.

 

So, I think you need to desc= ribe that the offerer indicates what it wants to receive.=

 

Then, you need to specify th= at, if the answerer accepts the offered parameters, it sends an answer, in = which it indicates what it wants to receive. It is fine to say that the ans= werer must indicate the same characteristics as the offerer, if that is required.

 

 

“The receiver SHALL ignor= e any unrecognized parameter or invalid parameter value.”<= /span>

 

First, In my opinion invalid pa= rameters values shall trigger an error.

 

Second, what is an unrecognized= parameter?

 

 

Also, the text does not say wha= t restrictions (if any) there are when it comes to modify the stream during= a session. Is it allowed to modify any/all characteristics?

 

 

Regards,

 

Christer

 

 

 

From: avt <avt-bounces@iet= f.org> On Behalf Of Christer Holmberg
Sent: Monday 17 May 2021 16:24
To: IETF AVTCore WG <avt@ietf.org= >
Cc: avtcore-chairs@ietf.o= rg; Murray S. Kucherawy <supe= ruser@gmail.com>; mmusic <mmus= ic@ietf.org>
Subject: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-= jpegxs-13

 

Hi,

 

I have performed the SDP direct= orate review of draft-ietf-payload-rtp-jpegxs-13.

 

Regards,

 

Christer

 

----

 

Q.1

 

I suggest converting section 7.= 2 to a separate main section, and change the name to "SDP Offer/Answer= Considerations". I don't think we need to consider other SDP usage th= an Offer/Answer.

 

 

Q.2. Regarding section 7.2.1.:<= o:p>

 

 

    "A Sess= ion Description Protocol (SDP) [RFC8866] media description SHALL be created= for each RTP stream."

 

This sentence is not needed.

 

 

     "= The information carried in the media type specification of

      = Section 7.1 has a specific mapping to the SDP fields, used to

      = describe RTP sessions.  This information is redundant with the

      = information found in the payload data (namely, in the JPEG XS header

      = segment) and SHALL be consistent with it."

 

In SDP offer/answer, you typica= lly indicate what you are willing to RECEIVE. In this case it seems like yo= u indicate what you are going to SEND. Is there a reason for that? I guess = that impacts Section 7.2.3 too.

 

 

Q.3. Regarding Section 7.2.3.:<= o:p>

 

     "= All parameters must be supported by both sides,"

 

In Section 7.2.1 you say that t= he receiver shall ignore unrecognized parameters. I ASSUME that you mean th= at the all the parameter defined in Section 7.2.1.

 

      = "i.e. the answerer SHALL either maintain all parameters or remove the = media format (payload

     &= nbsp; type) completely if one or more of the parameter values are not<= /o:p>

     &= nbsp; supported."

 

I don't understand what this me= an. According to Section 7.2.1, some of the parameters are OPTIONAL. Is the= answerer only allowed to reply with parameters that were present in the of= fer?

--_000_AM0PR07MB38607E9DDEB4FC8B86FC3FBB93269AM0PR07MB3860eurp_-- From nobody Mon May 24 14:15:14 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9673A0997; Mon, 24 May 2021 14:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvw8Ng0DDaoh; Mon, 24 May 2021 14:15:07 -0700 (PDT) Received: from smtp.egensajt.se (smtp.egensajt.se [194.68.80.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29B583A0990; Mon, 24 May 2021 14:15:06 -0700 (PDT) Received: from [192.168.2.137] (h77-53-37-81.cust.a3fiber.se [77.53.37.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id C900E20F79; Mon, 24 May 2021 23:15:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1621890901; bh=v8aephgQLJJs9M0oQiiR1jddTnLDgTsvKKcCwfxamZ0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=S54hpwKCYLjLROfQFC6rr5Piu6t1YJKY35/LcqDGjCcAhIjAxTVSRNwsZhc+Ry6NS 93EsY98BFRc9+xaD3poZEbJRg5rcOBxfshVSENNzcrNTNeiZSXKHp7y1+QOLEa09Ow HF/rAUOgC7JBmvVIembX88kTRlq1xyXtSQn8qhj4= To: avt@ietf.org, Benjamin Kaduk , The IESG , draft-ietf-avtcore-multi-party-rtt-mix@ietf.org, "avtcore-chairs@ietf.org" , Bernard Aboba References: <162139279927.706.12647899386073526674@ietfa.amsl.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Mon, 24 May 2021 23:14:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: <162139279927.706.12647899386073526674@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------CCE126EE60481894ACF986F7" Content-Language: sv Archived-At: Subject: Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-ietf-avtcore-multi-party-rtt-mix-18: Answer 3 - X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2021 21:15:13 -0000 This is a multi-part message in MIME format. --------------CCE126EE60481894ACF986F7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Continuing the answers: Den 2021-05-19 kl. 04:53, skrev Benjamin Kaduk via Datatracker: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-avtcore-multi-party-rtt-mix-18: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/ > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The abstract is perhaps pushing the boundary of length reasonable for an > abstract. > > There were a couple interesting remarks in the shepherd writeup: > > % The specification has not been implemented yet, so it is possible that > % issues could arise in implementation. This is more of a concern than > % for typical AVTCORE documents, since this specification is likely to > % become a regulatory requirement prior to advancing beyond Proposed > % Standard. > > Are there still no implementations? Are we happy with publishign the > specification at this time in the absence of implementations? [GH] There is an implementation of section 4.2 4.2.  multiparty mixing for multiparty-unaware endpoints It works well. It is true that there are no known implementations of the method for multiparty-aware endpoints. However the basic methods: the RTP-mixer and the centralized SIP conference model, and the base RTP transport for real-time text (RFC 4103) are all commonly implemented. > > % During review, the question was raised as to whether the specification > % will require development of an RTT mixer, or whether it could be made > % compatible with existing conferencing servers implementing Selective > % Forwarding. > > What was the outcome of the discussion? Should that be reflected in the > document? [GH] The discussion is concluded in section 1.2, and a note in 3.20. The first expected implementation environment is the traditional SIP centralized conference server and endpoints (for emergency services) , where traditional RTP-mixers are the dominating bases for implementations. It seems to me that we are closer to get implementations done by keeping to that well known technology than trying to apply selective forwarding for this case. > > Abstract > > mixer model. The possibility to implement the solution in a wide > range of existing RTP implementations made the RTP-mixer model be > selected to be fully specified in this document. > > It's a little surprising to see this claim given the absence (per the > shepherd writeup) of any actual implementations. [GH] The RTP-mixer is a general technology, specified in RFC 3550. It is very commonly applied in conference bridges since long, but for the other media; video and audio. But more important here is that the RTP-mixer makes use of just one RTP media stream to each receiver. Many implementations of RTP seem to have the limitation that they cannot handle more than one media stream per RTP media session. Requiring a multi-stream solution would have led to excluding a lot of potential current endpoints with two-party RTT implementations from becoming upgraded to RTT multiparty-aware endpoints. > > Section 1.2 > > Multiple sources per packet > A new "text" media subtype would be specified with up to 15 > sources in each packet. The mechanism would make use of the RTP > mixer model specified in RTP [RFC3550]. Text from up to 15 > sources can be included in each packet. [...] > > (How was the "15" number determined?) [GH] It is a limitation from the maximum size of the CSRC list in the RTP header defined in RFC 3550: " CSRC list: 0 to 15 items, 32 bits each The CSRC list identifies the contributing sources for the payload contained in this packet. The number of identifiers is given by the CC field. If there are more than 15 contributing sources, only 15 can be identified." In our case it is essential to have the sources identified, and complicated to go over this limitation. I suggest to add to the text in 1.2 to read: "The sources are indicated in strict order in the CSRC list of the RTP packets. The CSRC list can have up to 15 members. Therefore, text from up to 15 sources can be included in each packet." > > Section 2.3.2 > > A party receiving an offer containing the "rtt-mixer" SDP attribute > and being willing to use the RTP-mixer-based method of this > specification for sending or receiving or both sending and receiving > SHALL include the "rtt-mixer" SDP attribute in the corresponding > "text" media section in the answer. > > This requirement doesn't quite seem to match up with what I expect -- an > answerer that's willing to use rtt-mixer and also willing to use > something else seems to still be bound by the "SHALL include" in the > first paragraph, which makes the willingness to use something else a bit > irrelevant and precludes choosing the other option. Perhaps we want to > say only "chooses to use the RTP-mixer-based method of this > specification"? [GH] It says "willing" because also two-party coded real-time text is still allowed. The multi-party coding is expected to be applied when more than two parties participate in the call. So, the answerer is not willing to use another multiparty method. In order to make that clear, I suggest to insert this sentence before the discussion of other multiparty methods in 2.3.2: "  Even when the "rtt-mixer" attribute is successfully negotiated, the parties MAY send and receive two-party coded real-time text." > > Section 3.2 > > What purpose does the initial BOM serve? I note that, e.g., RFC 5198 > has an explicit BOM "MUST NOT appear at the beginning of these text > strings" and that RFC 4103 specifies UTF-8 encoding of the text. > I see in Section 3.17.4 (and 4.2.1) we mention that it might be used for > keepalive, but in rtt-mix don't we have lots of non-BOM keepalive > options? [GH] The initial BOM is for initial opening of ports and firewall paths so that traffic rapidly can start to flow both ways. In real-time text already the first real media packet with text is important, while for most other media (= video and audio) usually many hundred RTP packet flow before any important information carrying packet is sent. BOM is also said in Unicode to be required in the beginning of UNICODE streams, and that is negated by RFC 5198. RFC 4103 is a update of RFC 2793, published in May 2000. At that time RFC 2279 was the UTF-8 RFC. RFC 2279 did not mention any restrictions for use of BOM, so RFC 2793 specified the use from Unicode, For interoperability reasons we have not changed that in RFC 4103 and not in the current draft. So we can just realizr that we are not fully RFC 5198 compliant of historical and interoperational reasons. BOM is not recommended as keep-alive even if some implementations may use it. I suggest to add this sentence in 3.2: " This is useful in many configurations to open ports and firewalls and setting up the connection between the application and the network." > > Section 3.4 > > If the "CPS" value is reached, longer transmission intervals SHALL be > applied and only as much of the text queued for transmission SHALL be > sent at the end of each transmission interval that can be allowed > without exceeding the "CPS" value, until the transmission rate falls > under the "CPS" value again. [...] > > This doesn't seem as precisely specified as it could be, given that the > CPS rate is supposed to be enforced over "any 10-second interval". As > written, this seems to suggest that the entire 10-second history of > packet size/spacing needs to be retained, so that at each transmission > the earliest time for next transmission can be computed that retains the > CPS limit. It's not clear that there's real need for such a complicated > solution vs something that more bluntly backs off the transmit rate and > uses bucketed averages for tracking the transmission rate. [GH] I suggest to change the calculation of mean character rate in the first paragraph of 3.4 to: " as long as the mean character rate of new text to the receiver calculated over the last 10 one-second intervals does not exceed the "CPS" value of the receiver." That calculation method of character rate will then be remembered when reading other references to "CPS" > > (I have no idea why it's 330ms for a mixer and 300ms for a non-mixer, > but assume there is some reason for the difference.) [GH] I have now inserted an explanation in 3.4 as proposed in the DISCUSS resolution: "    The reason for the value 330 ms is that many sources of text will    transmit new text with 300 ms intervals during periods of    continuous user typing, and then reception in the mixer of such new    text will cause a combined transmission of the new text and the    unsent redundancy from the previous transmission. Only when the user    stops typing, the 330 ms interval will be applied to send the    redundancy." > > Section 3.6 > > Text received by a mixer from a participant SHOULD NOT be included in > transmission from the mixer to that participant, because the normal > behavior of the endpoint is to present locally-produced text locally. > > When would the SHOULD NOT be ignored? (How might a mixer know that the > other endpoint is not using the "normal behavior" of presenting > locally-produced text locally?) [GH] It is SHOULD just to allow specific applications to deviate. I have no reason to think that it would be useful, but I do not want to make it forbidden. Then all mixers and endpoints in that application environment would do it the same way or have a setting or control mechanism to select which solution to use. I suggest no change. > > Section 3.7 > > A mixer SHALL handle reception, recovery from packet loss, deletion > of superfluous redundancy, marking of possible text loss and deletion > of 'BOM' characters from each participant before queueing received > text for transmission to receiving participants. > > Are there specific references available for each of these operations? [GH] Yes. I suggest to add last " as specified in [RFC4103] for single-party sources and section 3.17  for multiparty sources (chained mixers). > > Section 3.9 > > The source with the oldest text received in the mixer or oldest > redundant text SHALL be next in turn to get all its available unsent > text transmitted. Any redundant repetitions of earlier transmitted > > Just to confirm: this is really *all* its available unsent text, not > just however much will fit in one packet/flight/etc.? Can a participant > "hog the mic" by continuing to append to that list even as transmission > has commenced? [GH] Section 3.9 is in answers to the DISCUSS suggested to be replaced by wording in 3.4, where the problem indicated here is amended. > > Section 3.13 > > It took me a bit of searching to realize that it is RFC 2198 that > specifies the additional header that includes the "timestamp offset" > field. A specific reference here (or maybe from an earlier section?) > would have helped me out. [GH] I suggest to include after the bullet list in section 3.10 the following:             "The principles from [RFC4103] apply for populating the header, the redundancy header and the data in the packet with specifics specified here and in the following sections." I hope it is OK to take it in pieces, with next piece coming soon. Thanks, Gunnar > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt -- Gunnar Hellström GHAccess gunnar.hellstrom@ghaccess.se --------------CCE126EE60481894ACF986F7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Continuing the answers:

Den 2021-05-19 kl. 04:53, skrev Benjamin Kaduk via Datatracker:
Benjamin Kaduk has entered the following ballot position for
draft-ietf-avtcore-multi-party-rtt-mix-18: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The abstract is perhaps pushing the boundary of length reasonable for an
abstract.

There were a couple interesting remarks in the shepherd writeup:

% The specification has not been implemented yet, so it is possible that
% issues could arise in implementation. This is more of a concern than
% for typical AVTCORE documents, since this specification is likely to
% become a regulatory requirement prior to advancing beyond Proposed
% Standard.

Are there still no implementations?  Are we happy with publishign the
specification at this time in the absence of implementations?

[GH] There is an implementation of section 4.2

4.2.  multiparty mixing for multiparty-unaware endpoints
It works well.

It is true that there are no known implementations of the method for multiparty-aware endpoints. However the basic methods: the RTP-mixer and the centralized SIP conference model, and the base RTP transport for real-time text (RFC 4103) are all commonly implemented. 


% During review, the question was raised as to whether the specification
% will require development of an RTT mixer, or whether it could be made
% compatible with existing conferencing servers implementing Selective
% Forwarding.

What was the outcome of the discussion?  Should that be reflected in the
document?
[GH] The discussion is concluded in section 1.2, and a note in 3.20.
The first expected implementation environment is the traditional SIP centralized conference server and endpoints (for emergency services) , where traditional RTP-mixers are the dominating bases for implementations. It seems to me that we are closer to get implementations done by keeping to that well known technology than trying to apply selective forwarding for this case. 


Abstract

   mixer model.  The possibility to implement the solution in a wide
   range of existing RTP implementations made the RTP-mixer model be
   selected to be fully specified in this document.

It's a little surprising to see this claim given the absence (per the
shepherd writeup) of any actual implementations.

[GH] The RTP-mixer is a general technology, specified in RFC 3550. It is very commonly applied in conference bridges since long, but for the other media; video and audio. But more important here is that the RTP-mixer makes use of just one RTP media stream to each receiver. Many implementations of RTP seem to have the limitation that they cannot handle more than one media stream per RTP media session. Requiring a multi-stream solution would have led to excluding a lot of potential current endpoints with two-party RTT implementations from becoming upgraded to RTT multiparty-aware endpoints. 


Section 1.2

   Multiple sources per packet
      A new "text" media subtype would be specified with up to 15
      sources in each packet.  The mechanism would make use of the RTP
      mixer model specified in RTP [RFC3550].  Text from up to 15
      sources can be included in each packet.  [...]

(How was the "15" number determined?)
[GH] It is a limitation from the maximum size of the CSRC list in the RTP header defined in RFC 3550:
"
 
CSRC list: 0 to 15 items, 32 bits each
      The CSRC list identifies the contributing sources for the payload
      contained in this packet.  The number of identifiers is given by
      the CC field.  If there are more than 15 contributing sources,
      only 15 can be identified."

In our case it is essential to have the sources identified, 
and complicated to go over this limitation.

I suggest to add to the text in 1.2 to read:
"The sources are indicated in strict order in the CSRC list of the RTP packets.
 The CSRC list can have up to 15 members. Therefore, text from up to 15 sources
 can be included in each packet."



Section 2.3.2

   A party receiving an offer containing the "rtt-mixer" SDP attribute
   and being willing to use the RTP-mixer-based method of this
   specification for sending or receiving or both sending and receiving
   SHALL include the "rtt-mixer" SDP attribute in the corresponding
   "text" media section in the answer.

This requirement doesn't quite seem to match up with what I expect -- an
answerer that's willing to use rtt-mixer and also willing to use
something else seems to still be bound by the "SHALL include" in the
first paragraph, which makes the willingness to use something else a bit
irrelevant and precludes choosing the other option.  Perhaps we want to
say only "chooses to use the RTP-mixer-based method of this
specification"?

[GH] It says "willing" because also two-party coded real-time text is still allowed. The multi-party coding is expected to be applied when more than two parties participate in the call.

So, the answerer is not willing to use another multiparty method.

In order to make that clear, I suggest to insert this sentence before the discussion of other multiparty methods in 2.3.2:

"  Even when the "rtt-mixer" attribute is successfully negotiated, the parties MAY send and receive two-party coded real-time text."




Section 3.2

What purpose does the initial BOM serve?  I note that, e.g., RFC 5198
has an explicit BOM "MUST NOT appear at the beginning of these text
strings" and that RFC 4103 specifies UTF-8 encoding of the text.
I see in Section 3.17.4 (and 4.2.1) we mention that it might be used for
keepalive, but in rtt-mix don't we have lots of non-BOM keepalive
options?

[GH] The initial BOM is for initial opening of ports and firewall paths so that traffic rapidly can start to flow both ways. In real-time text already the first real media packet with text is important, while for most other media (= video and audio) usually many hundred RTP packet flow before any important information carrying packet is sent. BOM is also said in Unicode to be required in the beginning of UNICODE streams, and that is negated by RFC 5198. RFC 4103 is a update of RFC 2793, published in May 2000. At that time RFC 2279 was the UTF-8 RFC. RFC 2279 did not mention any restrictions for use of BOM, so RFC 2793 specified the use from Unicode, For interoperability reasons we have not changed that in RFC 4103 and not in the current draft. So we can just realizr that we are not fully RFC 5198 compliant of historical and interoperational reasons.

BOM is not recommended as keep-alive even if some implementations may use it.

I suggest to add this sentence in 3.2: " This is useful in many configurations to open ports and firewalls and setting up the connection between the application and the network."


Section 3.4

   If the "CPS" value is reached, longer transmission intervals SHALL be
   applied and only as much of the text queued for transmission SHALL be
   sent at the end of each transmission interval that can be allowed
   without exceeding the "CPS" value, until the transmission rate falls
   under the "CPS" value again.  [...]

This doesn't seem as precisely specified as it could be, given that the
CPS rate is supposed to be enforced over "any 10-second interval".  As
written, this seems to suggest that the entire 10-second history of
packet size/spacing needs to be retained, so that at each transmission
the earliest time for next transmission can be computed that retains the
CPS limit.  It's not clear that there's real need for such a complicated
solution vs something that more bluntly backs off the transmit rate and
uses bucketed averages for tracking the transmission rate.

[GH] I suggest to change the calculation of mean character rate in the first paragraph of 3.4 to: " as long as the mean character rate of new text to the receiver calculated over the last 10 one-second intervals does not exceed the "CPS" value of the receiver."

That calculation method of character rate will then be remembered when reading other references to "CPS"


(I have no idea why it's 330ms for a mixer and 300ms for a non-mixer,
but assume there is some reason for the difference.)

[GH] I have now inserted an explanation in 3.4 as proposed in the DISCUSS resolution:

"    The reason for the value 330 ms is that many sources of text will
   transmit new text with 300 ms intervals during periods of
   continuous user typing, and then reception in the mixer of such new
   text will cause a combined transmission of the new text and the
   unsent redundancy from the previous transmission. Only when the user
   stops typing, the 330 ms interval will be applied to send the
   redundancy."


Section 3.6

   Text received by a mixer from a participant SHOULD NOT be included in
   transmission from the mixer to that participant, because the normal
   behavior of the endpoint is to present locally-produced text locally.

When would the SHOULD NOT be ignored?  (How might a mixer know that the
other endpoint is not using the "normal behavior" of presenting
locally-produced text locally?)
[GH] It is SHOULD just to allow specific applications to deviate. I have no reason to think that it would be useful, but I do not want to make it forbidden. Then all mixers and endpoints in that application environment would do it the same way or have a setting or control mechanism to select which solution to use. I suggest no change.

Section 3.7

   A mixer SHALL handle reception, recovery from packet loss, deletion
   of superfluous redundancy, marking of possible text loss and deletion
   of 'BOM' characters from each participant before queueing received
   text for transmission to receiving participants.

Are there specific references available for each of these operations?

[GH] Yes. I suggest to add last " as specified in [RFC4103] for single-party sources and section 3.17  for multiparty sources (chained mixers).



Section 3.9

   The source with the oldest text received in the mixer or oldest
   redundant text SHALL be next in turn to get all its available unsent
   text transmitted.  Any redundant repetitions of earlier transmitted

Just to confirm: this is really *all* its available unsent text, not
just however much will fit in one packet/flight/etc.?  Can a participant
"hog the mic" by continuing to append to that list even as transmission
has commenced?
[GH] Section 3.9 is in answers to the DISCUSS suggested to be replaced by wording in 3.4, where the problem indicated here is amended.

Section 3.13

It took me a bit of searching to realize that it is RFC 2198 that
specifies the additional header that includes the "timestamp offset"
field.  A specific reference here (or maybe from an earlier section?)
would have helped me out.
[GH] I suggest to include after the bullet list in section 3.10 the following:
            "The principles from [RFC4103] apply for populating the header, the redundancy header and the data in the packet with specifics specified here and in the following sections."

    

    
I hope it is OK to take it in pieces, with next piece coming
      soon.

    
Thanks,

    
Gunnar

    

    

      

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt


    

    
-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se

  


--------------CCE126EE60481894ACF986F7--


From nobody Tue May 25 00:37:23 2021
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55483A1942 for ; Tue, 25 May 2021 00:37:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0GQk4KcuBwA for ; Tue, 25 May 2021 00:37:09 -0700 (PDT)
Received: from mx-relay57-hz1.antispameurope.com (mx-relay57-hz1.antispameurope.com [94.100.132.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5801E3A1946 for ; Tue, 25 May 2021 00:37:00 -0700 (PDT)
Received: from mailgw1.iis.fraunhofer.de ([153.96.172.4]) by mx-relay57-hz1.antispameurope.com; Tue, 25 May 2021 09:36:53 +0200
Received: from mail.iis.fraunhofer.de (mail01.iis.fhg.de [153.96.171.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mailgw1.iis.fraunhofer.de (Postfix) with ESMTPS id 09A302400081 for ; Tue, 25 May 2021 09:36:50 +0200 (CEST)
Received: from [10.54.246.103] (153.96.171.210) by mail01.iis.fhg.de (2001:638:a0a:1111:fd91:8c2a:e4a5:e74e) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 25 May 2021 09:36:49 +0200
To: 
References:   
From: Thomas Richter 
Message-ID: <7aa5e890-47c5-cdb7-5657-26864cec3d4c@iis.fraunhofer.de>
Date: Tue, 25 May 2021 09:36:49 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [153.96.171.210]
X-ClientProxiedBy: mail03.iis.fhg.de (2001:638:a0a:1111:314f:f22c:4a37:b25a) To mail01.iis.fhg.de (2001:638:a0a:1111:fd91:8c2a:e4a5:e74e)
X-cloud-security-sender: thomas.richter@iis.fraunhofer.de
X-cloud-security-recipient: avt@ietf.org
X-cloud-security-crypt: load encryption module
X-cloud-security-Virusscan: CLEAN
X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-relay57-hz1.antispameurope.com with 1ECE11EC7A5
X-cloud-security-connect: mailgw1.iis.fraunhofer.de[153.96.172.4], TLS=1, IP=153.96.172.4
X-cloud-security-Digest: 7f116abaca5eb8551ce546fb2e0df88b
X-cloud-security: scantime:1.733
Archived-At: 
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 May 2021 07:37:23 -0000

Hi Christer, hi Tim,

> Unfortunately I dont think what you explain above is very clear in the 
> text.
> 
> Consider the following.
> 
> The offerer sends an offer. The offerer specifies the characteristics 
> that the offerer wants to receive. Similarly, the answer specifies the 
> characteristics that the answerer wants to receive  the answerer does 
> NOT specify what it is going to send. which I think the text is 
> currently describing.

Sorry to sound confused, but maybe you could explain a bit better. To my 
understanding, it is the offerer that describes what it offers to send, 
and not the other way around? Maybe I misunderstand something very 
fundamental? Sorry to ask these elementary questions, but this is 
important for the text.

> The receiver SHALL ignore any unrecognized parameter or invalid 
> parameter value.
> 
> First, In my opinion invalid parameters values shall trigger an error.
> 
> Second, what is an unrecognized parameter?

I wonder why we need to specify this, i.e. what a receive does about 
parameters it does not recognize? Essentially, this is a problem of 
"foreward compatibility". Wouldn't it be a matter of implementation 
whether the receiver accepts an offer (note well, the receiver), and 
attempts to decode a stream on a "best effort" basis, keeping in mind 
that the stream itself includes additional means to identify required 
capabilities necessary for a successful decode.

If that is not an option, we would/could need means to identify the type 
of parameters in a foreward compatible way. I.e., conventions by which 
we would identify in the future parameters a receiver can safely ignore 
and attempt to decode, and parameters a receiver cannot safely ignore.

However, I believe this is getting a bit out of hands...

> Also, the text does not say what restrictions (if any) there are when it 
> comes to modify the stream during a session. Is it allowed to modify 
> any/all characteristics?

My understanding is that you cannot modify characteristics during a 
session. If you need to modify, you need to setup a new session and 
cancel the current one. For JPEG XS stream decoders, one cannot expect 
that an instanciated decoder can decode from modified parameters in 
mid-stream level. That is, if you start decoding in full-HD, and then 
stream parameters become 8K, the decoder will have to abort.

Thanks for helping and clarifying,

Greetings,
	Thomas


From nobody Tue May 25 03:30:07 2021
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEFD3A0945; Tue, 25 May 2021 03:30:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.101
X-Spam-Level: ***
X-Spam-Status: No, score=3.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2EPQGg7Oond; Tue, 25 May 2021 03:29:59 -0700 (PDT)
Received: from smtp.egensajt.se (smtp.egensajt.se [193.42.159.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D56B3A093C; Tue, 25 May 2021 03:29:57 -0700 (PDT)
Received: from [192.168.2.137] (h77-53-37-81.cust.a3fiber.se [77.53.37.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 7B6412006F; Tue, 25 May 2021 12:29:52 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1621938592; bh=2u9flL+AuCKmMGXX3Lpjy9V825VqEeHSum2bWoFlwrI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=i1ebht9fizDIVWRapzzWj9+FLWZzhHyJO04mpU3Ncc2mhkCPCmO7mIbpdFbkmli9d vWK8VbWfHcEA3OOcv4tG6h5rBwdOIu0bG8Cbs9pscCpV79gYmsYmQHq9fkLG71+dDv 7s+Ed/NSnrzZ7L9J8utO6Emhp2+MtwHrAlgjVIaQ=
To: Benjamin Kaduk , The IESG 
Cc: draft-ietf-avtcore-multi-party-rtt-mix@ietf.org, avtcore-chairs@ietf.org,  avt@ietf.org, bernard.aboba@gmail.com
References: <162139279927.706.12647899386073526674@ietfa.amsl.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: 
Date: Tue, 25 May 2021 12:29:51 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: <162139279927.706.12647899386073526674@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------F2639ACF693555F432EB7ABB"
Content-Language: sv
Archived-At: 
Subject: Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-ietf-avtcore-multi-party-rtt-mix-18: Answer 4.
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 May 2021 10:30:05 -0000

This is a multi-part message in MIME format.
--------------F2639ACF693555F432EB7ABB
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Benjamin,

Continuing the answers with the last part.,

Den 2021-05-19 kl. 04:53, skrev Benjamin Kaduk via Datatracker:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-avtcore-multi-party-rtt-mix-18: Discuss
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/

> Section 3.14
>
>     The SSRC of the mixer for the RTT session SHALL be inserted in the
>     SSRC field of the RTP header.
>
> As written, this could be taken to say that the non-mixer endpoint
> should also use the SSRC of the mixer.
[GH] I suggest to change to:
" The SSRC header field SHALL contain the SSRC of the RTP session where 
the packet will be transmitted."
>
> Section 3.16
>
>     Confidentiality SHALL be considered when composing these fields.
>
> I think "privacy considerations" would be more relevant than
> "confidentiality".
[GH] Accepted. Changed to "Privacy considerations SHALL be taken..."
>
>     Similar considerations SHALL be taken as for other media.
>
> This seems rather vague and it's not really clear how the implementor is
> supposed to take action based on it.  (Note that media are typically
> straight over (S)RTP, but these reports are (S)RTCP, which admittedly is
> also over (S)RTP, but is still different.)
[GH] I propose to delete the sentence.

>
> Section 3.17.2
>
>     If it is known that only one source is active in the RTP session,
>     then it is likely that a gap equal to or larger than the agreed
>     number of redundancy generations (including the primary) causes text
>     loss.  [...]
>
> Some more care in description may be needed here, as the gap in RTP
> sequence numbers is measured in the RTP sequence units (e.g., time), but
> the redundancy generation number is just a dimensionless generation
> count.  We need to assume the max inter-packet spacing in order to
> convert that into a time value that is suitable for assuming loss.
[GH] The RTP sequence number steps by one for each new packet sent in 
the RTP session. It is the timestamp that is increased by the time.  
Real-time text is also unusual in that it can transmit with varying 
intervals and be silent when there is no new text to send. No change 
proposed.
>
>     evaluate if three or more packets were lost within one second.  If
>     this simple method is used, then a t140block SHOULD be created with a
>     marker for possible text loss [T140ad1] and associated with the SSRC
>     of the transmitter as a general input from the mixer.
>
> Does "input from the mixer" mean that it uses the mixer's SSRC value?
> Or is this injected by the mixer (in contrast to the previous paragraph,
> where it was the receiver that injects the marker for possible text
> loss)?
[GH] I suggest to change "transmitter" to "RTP session" to make it clear 
that it is the mixer.
>
> Section 3.17.3
>
>     If the packet is not the first packet from a source, then if the
>     second generation redundant data is available, its timestamp SHALL be
>     created by subtracting its timestamp offset from the RTP timestamp.
>     If the resulting timestamp is later than the latest retrieved data
>     from the same source, then the redundant data SHALL be retrieved and
>     appended to the receive buffer.  The process SHALL be continued in
>     the same way for the first generation redundant data.  After that,
>     the primary data SHALL be retrieved from the packet and appended to
>     the receive buffer for the source.
>
> I think I can come up with reordering scenarios that cause this
> procedure to discard data that would otherwise have recovered from loss.
[GH] Would it be sufficient to insert the words "and reordering" in the 
first two sentences in the paragraph to read:
"The receiver SHALL monitor the RTP sequence numbers of the received 
packets for gaps and packets out of order.
If a sequence number gap appears and still exists after some defined 
short time for jitter and reordering resolution, the packets in the gap 
SHALL be regarded as lost."
>
> Also, this procedure as written says that the primary data shall always
> be appended to the receive buffer (with no time check), which could
> result in doubled content in the case of reordering.
[GH] I suggest to change the last sentence in the paragraph to " After 
that, the timestamp of the packet SHALL be compared with the timestamp 
of the latest retrieved data from the same source and if it is later, 
then the primary data SHALL be retrieved from the packet and appended to 
the receive buffer for the source."
>
> Section 3.19
>
>     Security SHOULD be applied when possible regarding the capabilities
>     of the participating devices by use of SIP over TLS by default
>
> "Security" is not some all-encompassing attribute that can be
> generically applied; there are specific security properties that may or
> may not be achieved by any given mechanism, and it's generally worth
> being precise about what properties are (or are not) achieved.  So here
> we might say "security mechanisms to provide confidentiality and
> integrity protection and peer authentication SHOULD be applied".  We
> cannot in general achieve source authenticity with just SRTP when a
> mixer is involved, though RFC 8723 does specify a double-encryption
> mechanism that applies in some cases when there is a central media
> distributor.
[GH] Answered in the DISCUSS part.
>
>                                                               In
>     applications where legacy endpoints without security may exist, a
>     negotiation SHOULD be performed to decide if encryption on the media
>     level will be applied.  [...]
>
> How would endpoints know if legacy endpoints might exist?
[GH] Answered in the DISCUSS part.
>
> How would this negotiation be performed?
[GH] Answered in the DISCUSS part.
>
>     security levels.  The mixing for conference-unaware endpoints has
>     lower security level than the mixing method for conference-aware
>     endpoints, because there may be an opportunity for a malicious mixer
>     or a middleman to masquerade the source labels accompanying the text
>     streams in text format.  This is especially true if support of un-
>     encrypted SIP and media is supported because of lack of such support
>     in the target endpoints.  However, the mixing for conference-aware
>     endpoints as specified here also requires that the mixer can be
>     trusted.  [...]
>
> As the last sentence indicates, the provided reasoning in the first
> sentence is not really accurate, since the mixer could just as easily
> adjust the CSRC value in the header as change the label in the in-band
> text stream.  This does not inherently invalidate the claim that there
> are different security levels, though, as the correct behavior of the
> mixer seems easier to independently validate in the conference-aware
> endpoint case (with the well-formed RTP payloads providing information
> that can be validated out-of-band with other participants).  But I don't
> think this description should be left in the document as-is; it doesn't
> seem accurate.
>
> In the case of unencrypted media, it does seem technically true that it
> is easier for a non-mixer middleman to masquerade the source labels,
> since in that case it only adjusts the payload directly without needing
> to keep state on the RTP sender information and produce well-formed RTP
> headers after its adjustment.  But this is only a modest level of
> additional difficulty and does not reflect any kind of effective
> security control, so it may not be worth mentioning at all.
[GH] Answered in the DISCUSS part.
>
>     End-to-end encryption would require further work and could be based
>     on WebRTC as specified in Section 1.2.
>
> Is RFC 8723 not applicable to these scenarios at all?  I do not think it
> is WebRTC-specific.
[GH] Answered in the DISCUSS part.
>
> Section 3.21
>
>            Transmission of A2 and A3 as redundancy is planned for 330 ms
>     after packet 101 if no new text from A is ready to be sent before
>     that.
>
> I thought new text from *anyone* would trigger sending A2 and A3 as
> redundancy, per §3.9.
[GH] No, since A2 and A3 sent as redundancy only can be sent alone or 
together with new text from A, they should only be triggered to be sent 
when new text from A has arrived or the current transmission interval 
since last transmission from A has passed. I hope that is clear from 
"3.5 Only one source per packet."
>
>
> Is there any reason why the dummy offsets in 104 are 300/600 but the
> dummy offsets in 103 are 330/660?
[GH] There are dummy offsets in 102, 104 and 105. The ones which can be 
analyzed for the values are the ones in 104 and 105. They have the same 
values as they would have if there was redundancy on that level 
available for transmission at that time. Since the value is irrelevant, 
that is just one way to assign a "realistic" value.
>
> Section 4.2
>
>                 In order to expedite source switching, a user can, for
>     example, end its turn with a new line.
>
> How would a user know that there is a legacy endpoint in the coversation
> so as to choose to end its turn in this way?
[GH] It can be from experience or education. The first implementations 
are expected to be in emergency services, where the calling users in 
emergency may get multiparty-aware clients later than the emergency 
service call- takers. The call-takers can then be educated from the 
beginning to end their turns with a new line to expedite the switch so 
that new text from the caller is rapidly presented to another person in 
the service observing, or taking over the call. It is also quite normal 
in modern text communication, both real-time and messaging, to end turn 
with a new line.
>
> Section 4.2.2
>
>     *  A long pause (e.g., > 10 seconds) in received text from the
>        currently transmitted source
>
>     *  If text from one participant has been transmitted with text from
>        other sources waiting for transmission for a long time (e.g., > 1
>        minute) and none of the other suitable points for switching has
>
> I think I'm confused how we could hit the 1 minute timer before the 10
> seconds timer has triggered.
[GH] If one user is generating text continously, e.g. making a live 
transcription of someone making a speech, then it may happen that the 
text neither has full stop anywhere, nor any pause longer than 10 
seconds appears within one minute or more. In that situation it is fair 
that waiting text is allowed to break in and be given turn.
>
> Section 11
>
> I think that the obvious attacks involving control characters are
> addressed in one way or another, but it might be worth a reminder to
> implementors that control characters should not be allowed to let one
> user's content affect the display of other users' content, or the
> presentation-format's label of the sender, etc.

[GH] I suggest to insert in section 11:

"      Participants with malicious intentions may also try to disturb 
the presentation by sending incomplete or malformed control codes. 
Handling of text from the different sources by the receivers MUST 
therefore be well separated so that the effects of such actions only 
affect text from the source causing the action. "


>
> It might be appropriate to have yet another reminder here that SRTP is
> the recommended mode of operation.
[GH] I suggest to insert the following in section 11:
"As already stated in , 
security in media SHOULD be applied by using DTLS-SRTP  on the media level."
>
>     The requirement to transfer information about the user in RTCP
>     reports in SDES, CNAME, and NAME fields, and in conference
>     notifications, for creation of labels may have privacy concerns as
>     already stated in RFC 3550 [RFC3550], [...]
>
> Could you point me to where this is stated in RFC 3550?  I looked in the
> security considerations (section 14) and searched for all instances of
> "CNAME", but didn't see discussion about SDES/CNAME/NAME being privacy
> sensitive.
[GH] In RFC 3550, sentences 2 and 3, it is said: "

For example, an impostor can fake source or destination
    network addresses, or change the header or payload.  Within RTCP, the
    CNAME and NAME information may be used to impersonate another
    participant. "

>
> Section 13.1
>
> RFC 8825 is not currently referenced in any context that specifically
> requires it to be listed as a normative reference.  This may suggest
> that it should be referenced in more places (e.g., in the discussion of
> gateway considerations with WebRTC).
[GH] I think it is sufficient to reference RFC 8865 in the WebRTC 
gateway section. Therefore my proposal is to move the reference to RFC 
8825 to informational.
>
> NITS
>
> Section 1
>
>     Use of RTT is increasing, and specifically, use in emergency calls is
>     increasing.  Emergency call use requires multiparty mixing.  [...]
>
> I expect the conclusion that emergency-call use requires mixing to be
> non-intuitive to many readers, so additional explanation might be
> helpful.
[GH] I propose extending the sentence to: " Emergency call use requires 
multiparty mixing because it is common that one agent needs to transfer 
the call to another specialized agent but is obliged to stay on the call 
at least to verify that the transfer was successful. "
>
>                                                                  RFC 4103
>     "RTP Payload for Text Conversation" mixer implementations can use
>     traditional RTP functions for source identification, but the
>
> The word "mixer" (or even "mix") does not appear in RFC 4103, so I'm not
> sure how to interpret "RFC 4103 mixer implementations".  Perhaps it is
> an RFC 3550 mixer acting on RFC 4103 payloads?
[GH] I do not think that other RTP payload type specifications specify 
how RTP mixing shall be applied either. It is just assumed that RFC 3550 
RTP mixing is used. Anyway, I suggest to change the sentence to: "Mixer 
implementations for RFC 4103 "RTP Payload for Text Conversation" can use 
traditional RFC 3550 RTP functions for mixing and source identification."
>
>     The document updates [RFC4103] by introducing an attribute for
>     indicating capability for the RTP-mixer-based multiparty mixing case
>     and rules for source indications and interleaving of text from
>     different sources.
>
> I think "indicating capability for the RTP-mixer-based multiparty mixing
> case" needs another verb.
[GH] My non-English background makes me not realize the problem. Will it 
be better with "declaring support of" instead of "indicating capability 
for". If so, there may be a couple of other places where similar wording 
should be changed.
>
> Section 2.2
>
>     A party acting as a mixer, which has not negotiated any method for
>     true multiparty RTT handling, but negotiated a "text/red" or "text/
>     t140" format in a session with a participant SHOULD in order to
>     maintain interoperability, if nothing else is specified for the
>     application, format transmitted text to that participant to be
>     suitable to present on a multiparty-unaware endpoint as further
>     specified in Section 4.2.
>
> comma after "SHOULD".
> The whole sentence is a bit long, though, and the parenthetical "if
> nothing else is specified for the application" is somewhat in the way in
> its current location.  Further reworking may be in order.
[GH] I propose to change to:
"A mixer SHOULD by default format and transmit text to a call 
participant to be suitable to present on a multiparty-unaware endpoint 
which has not negotiated any method for true multiparty RTT handling, 
but negotiated a "text/red" or "text/t140" format in a session. This 
SHOULD be done if nothing else is specified for the application in order 
to maintain interoperability. Section 4.2 specifies how this mixing is 
done."
>
> I'd also consider s/format transmitted text/transmit formatted text/ or
> /format text transmitted/.
[GH] Included above
>
> Section 2.3.4
>
>     If the modified offer deletes indication of support for multiparty
>     real-time text by excluding the "rtt-mixer" SDP attribute, the answer
>     MUST NOT contain the "rtt-mixer" attribute, and both parties SHALL
>     after processing the SDP exchange NOT send real-time text formatted
>     for multiparty-aware parties according to this specification.
>
> The BCP 14 keyword "SHALL NOT" is supposed to appear as the specific
> phrase, so something like "SHALL NOT, after processing the SDP exchange,
> send" seems more appropriate.
[GH] I propose to change to:
"If the modified offer deletes indication of support for multiparty 
real-time text by excluding the "rtt-mixer" SDP attribute, the answer 
MUST NOT contain the "rtt-mixer" attribute. After processing this SDP 
exchange, the parties MUST NOT send real-time text formatted for 
multiparty-aware parties according to this specification."
>
> Section 3.4
>
>     transmission MUST then be made at T140block borders.  See also
>     Section 8
>
> full stop at end of sentence.
[GH] Accepted.
>
> Section 3.10
>
>     The mixer SHALL compose and transmit an RTP packet to a receiver when
>     one of the following conditions has occurred:
>
> Maybe "one or more" (or "one or both")?
[GH] Accepted.
>
> Section 3.16
>
>     Confidentiality SHALL be considered when composing these fields.
>     They contain name and address information that may be sensitive to
>     transmit in its entirety e.g., to unauthenticated participants.
>
> comma before "e.g." (as well as after)
[GH] Accepted.
>
> Section 3.17
>
>     presentation areas for each source.  Other receiver roles, such as
>     gateways or chained mixers are also feasible, and requires
>     consideration if the stream shall just be forwarded, or distributed
>
> "such as gateways or chained mixers" seems like a parenthetical phrase
> that should be offset by commas on both sides.
[GH] Accepted.
>
> Also, "require consideration" seems to match up better with the plural
> "roles".
[GH] I suggest to start a new sentence "They require considerations..."
>
> Section 3.17.3
>
>     When a packet is received in an RTP session using the packetization
>     for multiparty-aware endpoints, its T140blocks SHALL be extracted in
>     the following way.  The description is adapted to the default
>     redundancy case using the original and two redundant generations.
>
> Is this supposed to imply that the extension to the generic case with
> other levels of redundancy is trivial for the reader to perform?
[GH] Yes. Should that be indicated?
>
> Section 3.18
>
>     This solution has good performance with low text delays as long as
>     the sum of characters per second during any 10-second interval sent
>     from a number of simultaneously sending participants to a receiving
>     participant does not reach the 'CPS' value.  [...]
>
> "sum of characters per second during any 10-second interval" seems to
> mean "compute CPS for each second, then add them up".  I don't think
> that's the intended meaning.
[GH] I suggest: "as long as the mean number of characters per second 
sent during any 10-second interval from a number of simultaneously 
sending participants to a receiving participant, does not reach the 
'CPS' value."
>
>                                     Only in large unmanaged conferences
>     with a high number of participants there may on very rare occasions
>     appear situations when many participants happen to send text
>     simultaneously, resulting in unpleasantly jerky presentation of text
>     from each sending participant.  [...]
>
> This sentence seems a bit long and winding.
[GH] I suggest to divide to: "Only in large unmanaged conferences with a 
high number of participants there may on very rare occasions appear 
situations when many participants happen to send text simultaneously. In 
such circumstances, the result may be unpleasantly jerky presentation of 
text from each sending participant."
>
> Section 3.20
>
>        Offer example for "text/red" format including multiparty
>        and security:
>              a=fingerprint: (fingerprint1)
>
> I think it would be preferred to make up some random fingerprints and
> use them instead of the placeholder string (throughout).
[GH] I had the opposite reaction in an earlier review, when I had random 
fingerprints. I suggest to keep as is.
>
> Section 3.21
>
>     offset 660 ms.  The timestamp of packet 106 minus 660 is 20500 which
>     is the timestamp of packet 102 THAT was received.  So B1 does not
>
> I don't see why "THAT" needs to be in all majuscule letters.
[GH] Right. Accepted.
>
> Section 3.22
>
>     to transmission to a receiver.  The value MAY be modified in the
>     "CPS" parameter of the FMTP attribute in the media section for the
>     "text/t140" media.  [...]
>
> RFC 4103 seems to show the lowercase "cps" parameter name (there are
> subsequent occurrences that I do not quote).
[GH] Thanks , all changed to lower case.
>
> Section 4.2
>
>     one presentation area.  The mixer SHALL group text in suitable groups
>     and prepare for presentation of them by inserting a new line between
>     them if the transmitted text did not already end with a new line.  A
>
> Is "new line" specified somewhere?  Up in toplevel §4 we cover the
> unicode line separator and CRLF sequences but don't use the phrase "new
> line".
[GH] "new line (line separator or CRLF)" is used in a number of places. 
I suggest to modify this one to:
"the mixer SHALL insert a line separator if the already transmitted text 
did not end with a new line (line separator or CRLF)"
>
> Section 4.2.2
>
>     Information available to the mixer for composing the label may
>     contain sensitive personal information that SHOULD not be revealed in
>
> "SHOULD NOT" in all caps
[GH]Accepted
>
>     sessions not securely authenticated and protected.  Integrity
>
> "confidentiality protected"
[GH] Accepted
>
>     considerations regarding how much personal information is included in
>     the label SHOULD therefore be taken when composing the label.
>
> I don't think "integrity" is the right word here.
[GH] Change to "Privacy" is proposed.
>
> Section 11
>
>     Therefore, the mixer needs to be trusted to achieve security in
>     confidentiality and integrity.  [...]
>
> s/trusted to achieve security in confidentiality and integrity/trusted
> to maintain confidentiality and integrity of the RTT data/
[GH] Accepted
>
>     The requirement to transfer information about the user in RTCP
>     reports in SDES, CNAME, and NAME fields, and in conference
>     notifications, for creation of labels may have privacy concerns as
>
> There's something awry with the commas around "for creation of labels".
[GH] I suggest to split in two sentences: "**When used for creation of 
readable labels in the presentation, the receiving user will then get a 
more symbolic label for the source."


[GH]Again, thanks for a thorough review and many good proposals for changes.

Regards

Gunnar

-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se


--------------F2639ACF693555F432EB7ABB
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Benjamin,

    
Continuing the answers with the last part.,

    

    
Den 2021-05-19 kl. 04:53, skrev
      Benjamin Kaduk via Datatracker:

    

    

      
Benjamin Kaduk has entered the following ballot position for
draft-ietf-avtcore-multi-party-rtt-mix-18: Discuss

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/

    

    

    

      
Section 3.14

   The SSRC of the mixer for the RTT session SHALL be inserted in the
   SSRC field of the RTP header.

As written, this could be taken to say that the non-mixer endpoint
should also use the SSRC of the mixer.

    

    [GH] I suggest to change to:

      " The SSRC header field SHALL contain the SSRC of the RTP session
      where the packet will be transmitted."

    

      

Section 3.16

   Confidentiality SHALL be considered when composing these fields.

I think "privacy considerations" would be more relevant than
"confidentiality".

    

    [GH] Accepted. Changed to "Privacy
      considerations SHALL be taken..."

    

      

   Similar considerations SHALL be taken as for other media.

This seems rather vague and it's not really clear how the implementor is
supposed to take action based on it.  (Note that media are typically
straight over (S)RTP, but these reports are (S)RTCP, which admittedly is
also over (S)RTP, but is still different.)

    

    [GH] I propose to delete the sentence.

    

    

      

Section 3.17.2

   If it is known that only one source is active in the RTP session,
   then it is likely that a gap equal to or larger than the agreed
   number of redundancy generations (including the primary) causes text
   loss.  [...]

Some more care in description may be needed here, as the gap in RTP
sequence numbers is measured in the RTP sequence units (e.g., time), but
the redundancy generation number is just a dimensionless generation
count.  We need to assume the max inter-packet spacing in order to
convert that into a time value that is suitable for assuming loss.

    

    [GH] The RTP sequence number steps by one for
      each new packet sent in the RTP session. It is the timestamp that
      is increased by the time.  Real-time text is also unusual in that
      it can transmit with varying intervals and be silent when there is
      no new text to send. No change proposed.

    

      

   evaluate if three or more packets were lost within one second.  If
   this simple method is used, then a t140block SHOULD be created with a
   marker for possible text loss [T140ad1] and associated with the SSRC
   of the transmitter as a general input from the mixer.

Does "input from the mixer" mean that it uses the mixer's SSRC value?
Or is this injected by the mixer (in contrast to the previous paragraph,
where it was the receiver that injects the marker for possible text
loss)?

    

    [GH] I suggest to change "transmitter" to "RTP
      session" to make it clear that it is the mixer.

    

      

Section 3.17.3

   If the packet is not the first packet from a source, then if the
   second generation redundant data is available, its timestamp SHALL be
   created by subtracting its timestamp offset from the RTP timestamp.
   If the resulting timestamp is later than the latest retrieved data
   from the same source, then the redundant data SHALL be retrieved and
   appended to the receive buffer.  The process SHALL be continued in
   the same way for the first generation redundant data.  After that,
   the primary data SHALL be retrieved from the packet and appended to
   the receive buffer for the source.

I think I can come up with reordering scenarios that cause this
procedure to discard data that would otherwise have recovered from loss.

    

    [GH] Would it be sufficient to insert the
      words "and reordering" in the first two sentences in the paragraph
      to read: 

      "The receiver SHALL monitor the RTP sequence numbers of the
      received packets for gaps and packets out of order.

      If a sequence number gap appears and still exists after some
      defined short time for jitter and
        reordering resolution, the packets in the gap SHALL be
      regarded as lost."

    
    

      

Also, this procedure as written says that the primary data shall always
be appended to the receive buffer (with no time check), which could
result in doubled content in the case of reordering.

    

    [GH] I suggest to change the last sentence in
      the paragraph to " After that, the timestamp of the packet SHALL
      be compared with the timestamp of the latest retrieved data from
      the same source and if it is later, then the primary data SHALL be
      retrieved from the packet and appended to the receive buffer for
      the source."

    

      

Section 3.19

   Security SHOULD be applied when possible regarding the capabilities
   of the participating devices by use of SIP over TLS by default

"Security" is not some all-encompassing attribute that can be
generically applied; there are specific security properties that may or
may not be achieved by any given mechanism, and it's generally worth
being precise about what properties are (or are not) achieved.  So here
we might say "security mechanisms to provide confidentiality and
integrity protection and peer authentication SHOULD be applied".  We
cannot in general achieve source authenticity with just SRTP when a
mixer is involved, though RFC 8723 does specify a double-encryption
mechanism that applies in some cases when there is a central media
distributor.

    

    [GH] Answered in the DISCUSS part.

    

      

                                                             In
   applications where legacy endpoints without security may exist, a
   negotiation SHOULD be performed to decide if encryption on the media
   level will be applied.  [...]

How would endpoints know if legacy endpoints might exist?

    

    [GH] Answered in the DISCUSS part.
    

      

How would this negotiation be performed?

    

    [GH] Answered in the DISCUSS part.
    

      

   security levels.  The mixing for conference-unaware endpoints has
   lower security level than the mixing method for conference-aware
   endpoints, because there may be an opportunity for a malicious mixer
   or a middleman to masquerade the source labels accompanying the text
   streams in text format.  This is especially true if support of un-
   encrypted SIP and media is supported because of lack of such support
   in the target endpoints.  However, the mixing for conference-aware
   endpoints as specified here also requires that the mixer can be
   trusted.  [...]

As the last sentence indicates, the provided reasoning in the first
sentence is not really accurate, since the mixer could just as easily
adjust the CSRC value in the header as change the label in the in-band
text stream.  This does not inherently invalidate the claim that there
are different security levels, though, as the correct behavior of the
mixer seems easier to independently validate in the conference-aware
endpoint case (with the well-formed RTP payloads providing information
that can be validated out-of-band with other participants).  But I don't
think this description should be left in the document as-is; it doesn't
seem accurate.

In the case of unencrypted media, it does seem technically true that it
is easier for a non-mixer middleman to masquerade the source labels,
since in that case it only adjusts the payload directly without needing
to keep state on the RTP sender information and produce well-formed RTP
headers after its adjustment.  But this is only a modest level of
additional difficulty and does not reflect any kind of effective
security control, so it may not be worth mentioning at all.

    

    [GH] Answered in the DISCUSS part.
    

      

   End-to-end encryption would require further work and could be based
   on WebRTC as specified in Section 1.2.

Is RFC 8723 not applicable to these scenarios at all?  I do not think it
is WebRTC-specific.

    

    [GH] Answered in the DISCUSS part.
    

      

Section 3.21

          Transmission of A2 and A3 as redundancy is planned for 330 ms
   after packet 101 if no new text from A is ready to be sent before
   that.

I thought new text from *anyone* would trigger sending A2 and A3 as
redundancy, per §3.9.

    

    [GH] No, since A2 and A3 sent as redundancy
      only can be sent alone or together with new text from A, they
      should only be triggered to be sent when new text from A has
      arrived or the current transmission interval since last
      transmission from A has passed. I hope that is clear from "3.5
      Only one source per packet."

    

      


Is there any reason why the dummy offsets in 104 are 300/600 but the
dummy offsets in 103 are 330/660?

    

    [GH] There are dummy offsets in 102, 104 and
      105. The ones which can be analyzed for the values are the ones in
      104 and 105. They have the same values as they would have if there
      was redundancy on that level available for transmission at that
      time. Since the value is irrelevant, that is just one way to
      assign a "realistic" value.

    

      

Section 4.2

               In order to expedite source switching, a user can, for
   example, end its turn with a new line.

How would a user know that there is a legacy endpoint in the coversation
so as to choose to end its turn in this way?

    

    [GH] It can be from experience or education.
      The first implementations are expected to be in emergency
      services, where the calling users in emergency may get
      multiparty-aware clients later than the emergency service call-
      takers. The call-takers can then be educated from the beginning to
      end their turns with a new line to expedite the switch so that new
      text from the caller is rapidly presented to another person in the
      service observing, or taking over the call. It is also quite
      normal in modern text communication, both real-time and messaging,
      to end turn with a new line. 

    

      

Section 4.2.2

   *  A long pause (e.g., > 10 seconds) in received text from the
      currently transmitted source

   *  If text from one participant has been transmitted with text from
      other sources waiting for transmission for a long time (e.g., > 1
      minute) and none of the other suitable points for switching has

I think I'm confused how we could hit the 1 minute timer before the 10
seconds timer has triggered.

    

    [GH] If one user is generating text
      continously, e.g. making a live transcription of someone making a
      speech, then it may happen that the text neither has full stop
      anywhere, nor any pause longer than 10 seconds appears within one
      minute or more. In that situation it is fair that waiting text is
      allowed to break in and be given turn.  

    

      

Section 11

I think that the obvious attacks involving control characters are
addressed in one way or another, but it might be worth a reminder to
implementors that control characters should not be allowed to let one
user's content affect the display of other users' content, or the
presentation-format's label of the sender, etc.

    

    
[GH] I suggest to insert in section 11:

    
"      Participants with malicious
        intentions may also try to disturb the presentation by sending
        incomplete or malformed control codes. Handling of text from the
        different sources by the receivers MUST therefore be well
        separated so that the effects of such actions only affect text
        from the source causing the action. "

            

            

    

    

      

It might be appropriate to have yet another reminder here that SRTP is
the recommended mode of operation.

    

    [GH] I suggest to insert the following in
      section 11:

      "As already stated in <xref target="security2"
      format="default"/>, security in media SHOULD be applied by
      using DTLS-SRTP <xref target="RFC5764" format="default"/> on
      the media level."
    

      

   The requirement to transfer information about the user in RTCP
   reports in SDES, CNAME, and NAME fields, and in conference
   notifications, for creation of labels may have privacy concerns as
   already stated in RFC 3550 [RFC3550], [...]

Could you point me to where this is stated in RFC 3550?  I looked in the
security considerations (section 14) and searched for all instances of
"CNAME", but didn't see discussion about SDES/CNAME/NAME being privacy
sensitive.

    

    [GH] In RFC 3550, sentences 2 and 3, it is said: "

    
For example, an impostor can fake source or destination
   network addresses, or change the header or payload.  Within RTCP, the
   CNAME and NAME information may be used to impersonate another
   participant. "

    

      

Section 13.1

RFC 8825 is not currently referenced in any context that specifically
requires it to be listed as a normative reference.  This may suggest
that it should be referenced in more places (e.g., in the discussion of
gateway considerations with WebRTC).

    

    [GH] I think it is sufficient to reference RFC
      8865 in the WebRTC gateway section. Therefore my proposal is to
      move the reference to RFC 8825 to informational.

    

      

NITS

Section 1

   Use of RTT is increasing, and specifically, use in emergency calls is
   increasing.  Emergency call use requires multiparty mixing.  [...]

I expect the conclusion that emergency-call use requires mixing to be
non-intuitive to many readers, so additional explanation might be
helpful.

    

    [GH] I propose extending the sentence to: "
      Emergency call use requires multiparty mixing because it is common
      that one agent needs to transfer the call to another specialized
      agent but is obliged to stay on the call at least to verify that
      the transfer was successful. "

    

      

                                                                RFC 4103
   "RTP Payload for Text Conversation" mixer implementations can use
   traditional RTP functions for source identification, but the

The word "mixer" (or even "mix") does not appear in RFC 4103, so I'm not
sure how to interpret "RFC 4103 mixer implementations".  Perhaps it is
an RFC 3550 mixer acting on RFC 4103 payloads?

    

    [GH] I do not think that other RTP payload
      type specifications specify how RTP mixing shall be applied
      either. It is just assumed that RFC 3550 RTP mixing is used.
      Anyway, I suggest to change the sentence to: "Mixer
      implementations for RFC 4103 "RTP Payload for Text Conversation"
      can use traditional RFC 3550 RTP functions for mixing and source
      identification."

    

      

   The document updates [RFC4103] by introducing an attribute for
   indicating capability for the RTP-mixer-based multiparty mixing case
   and rules for source indications and interleaving of text from
   different sources.

I think "indicating capability for the RTP-mixer-based multiparty mixing
case" needs another verb.

    

    [GH] My non-English background makes me not
      realize the problem. Will it be better with "declaring support of"
      instead of "indicating capability for". If so, there may be a
      couple of other places where similar wording should be changed.

    

      

Section 2.2

   A party acting as a mixer, which has not negotiated any method for
   true multiparty RTT handling, but negotiated a "text/red" or "text/
   t140" format in a session with a participant SHOULD in order to
   maintain interoperability, if nothing else is specified for the
   application, format transmitted text to that participant to be
   suitable to present on a multiparty-unaware endpoint as further
   specified in Section 4.2.

comma after "SHOULD".
The whole sentence is a bit long, though, and the parenthetical "if
nothing else is specified for the application" is somewhat in the way in
its current location.  Further reworking may be in order.

    

    [GH] I propose to change to: 

    "A mixer SHOULD by default format and transmit text to a call
    participant to be suitable to present on a multiparty-unaware
    endpoint which has not negotiated any method for true multiparty RTT
    handling, but negotiated a "text/red" or "text/t140" format in a
    session. This SHOULD be done if nothing else is specified for the
    application in order to maintain interoperability. Section 4.2
    specifies how this mixing is done."

    

      

I'd also consider s/format transmitted text/transmit formatted text/ or
/format text transmitted/.

    

    [GH] Included above

    

      

Section 2.3.4

   If the modified offer deletes indication of support for multiparty
   real-time text by excluding the "rtt-mixer" SDP attribute, the answer
   MUST NOT contain the "rtt-mixer" attribute, and both parties SHALL
   after processing the SDP exchange NOT send real-time text formatted
   for multiparty-aware parties according to this specification.

The BCP 14 keyword "SHALL NOT" is supposed to appear as the specific
phrase, so something like "SHALL NOT, after processing the SDP exchange,
send" seems more appropriate.

    

    [GH] I propose to change to:

    "If the modified offer deletes indication of support for multiparty
    real-time text by excluding the "rtt-mixer" SDP attribute, the
    answer MUST NOT contain the "rtt-mixer" attribute. After processing
    this SDP exchange, the parties MUST NOT send real-time text
    formatted for multiparty-aware parties according to this
    specification."

    

      

Section 3.4

   transmission MUST then be made at T140block borders.  See also
   Section 8

full stop at end of sentence.

    

    [GH] Accepted.

    

      

Section 3.10

   The mixer SHALL compose and transmit an RTP packet to a receiver when
   one of the following conditions has occurred:

Maybe "one or more" (or "one or both")?

    

    [GH] Accepted. 

    

      

Section 3.16

   Confidentiality SHALL be considered when composing these fields.
   They contain name and address information that may be sensitive to
   transmit in its entirety e.g., to unauthenticated participants.

comma before "e.g." (as well as after)

    

    [GH] Accepted.

    

      

Section 3.17

   presentation areas for each source.  Other receiver roles, such as
   gateways or chained mixers are also feasible, and requires
   consideration if the stream shall just be forwarded, or distributed

"such as gateways or chained mixers" seems like a parenthetical phrase
that should be offset by commas on both sides.

    

    [GH] Accepted.

    

      

Also, "require consideration" seems to match up better with the plural
"roles".

    

    [GH] I suggest to start a new sentence "They
      require considerations..."

    

      

Section 3.17.3

   When a packet is received in an RTP session using the packetization
   for multiparty-aware endpoints, its T140blocks SHALL be extracted in
   the following way.  The description is adapted to the default
   redundancy case using the original and two redundant generations.

Is this supposed to imply that the extension to the generic case with
other levels of redundancy is trivial for the reader to perform?

    

    [GH] Yes. Should that be indicated?

    

      

Section 3.18

   This solution has good performance with low text delays as long as
   the sum of characters per second during any 10-second interval sent
   from a number of simultaneously sending participants to a receiving
   participant does not reach the 'CPS' value.  [...]

"sum of characters per second during any 10-second interval" seems to
mean "compute CPS for each second, then add them up".  I don't think
that's the intended meaning.

    

    [GH] I suggest: "as long as the mean number of
      characters per second sent during any 10-second interval from a
      number of simultaneously sending participants to a receiving
      participant, does not reach the 'CPS' value."

    

      

                                   Only in large unmanaged conferences
   with a high number of participants there may on very rare occasions
   appear situations when many participants happen to send text
   simultaneously, resulting in unpleasantly jerky presentation of text
   from each sending participant.  [...]

This sentence seems a bit long and winding.

    

    [GH] I suggest to divide to: "Only in large
      unmanaged conferences with a high number of participants there may
      on very rare occasions appear situations when many participants
      happen to send text simultaneously. In such circumstances, the
      result may be unpleasantly jerky presentation of text from each
      sending participant."

    

      

Section 3.20

      Offer example for "text/red" format including multiparty
      and security:
            a=fingerprint: (fingerprint1)

I think it would be preferred to make up some random fingerprints and
use them instead of the placeholder string (throughout).

    

    [GH] I had the opposite reaction in an earlier
      review, when I had random fingerprints. I suggest to keep as is.

    

      

Section 3.21

   offset 660 ms.  The timestamp of packet 106 minus 660 is 20500 which
   is the timestamp of packet 102 THAT was received.  So B1 does not

I don't see why "THAT" needs to be in all majuscule letters.

    

    [GH] Right. Accepted.

    

      

Section 3.22

   to transmission to a receiver.  The value MAY be modified in the
   "CPS" parameter of the FMTP attribute in the media section for the
   "text/t140" media.  [...]

RFC 4103 seems to show the lowercase "cps" parameter name (there are
subsequent occurrences that I do not quote).

    

    [GH] Thanks , all changed to lower case.

    

      

Section 4.2

   one presentation area.  The mixer SHALL group text in suitable groups
   and prepare for presentation of them by inserting a new line between
   them if the transmitted text did not already end with a new line.  A

Is "new line" specified somewhere?  Up in toplevel §4 we cover the
unicode line separator and CRLF sequences but don't use the phrase "new
line".

    

    [GH] "new line (line separator or CRLF)" is
      used in a number of places. I suggest to modify this one to: 

      "the mixer SHALL insert a line separator if the already
      transmitted text did not end with a new line (line separator or
      CRLF)"

    

      

Section 4.2.2

   Information available to the mixer for composing the label may
   contain sensitive personal information that SHOULD not be revealed in

"SHOULD NOT" in all caps

    

    [GH]Accepted

    

      

   sessions not securely authenticated and protected.  Integrity

"confidentiality protected"

    

    [GH] Accepted

    

      

   considerations regarding how much personal information is included in
   the label SHOULD therefore be taken when composing the label.

I don't think "integrity" is the right word here.

    

    [GH] Change to "Privacy" is proposed.

    

      

Section 11

   Therefore, the mixer needs to be trusted to achieve security in
   confidentiality and integrity.  [...]

s/trusted to achieve security in confidentiality and integrity/trusted
to maintain confidentiality and integrity of the RTT data/

    

    [GH] Accepted

    

      

   The requirement to transfer information about the user in RTCP
   reports in SDES, CNAME, and NAME fields, and in conference
   notifications, for creation of labels may have privacy concerns as

There's something awry with the commas around "for creation of labels".



    

    [GH] I suggest to split in two sentences: "
      When used for creation of readable labels in the presentation,
      the receiving user will then get a more symbolic label for the
      source."

    

      

    

    


      

    
[GH]Again, thanks for a thorough review and
        many good proposals for changes.

    
Regards

    
Gunnar

    

    

      

    

    
-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se

  


--------------F2639ACF693555F432EB7ABB--


From nobody Tue May 25 12:38:55 2021
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36C43A1ACF; Tue, 25 May 2021 12:38:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7gCiAwPrKbk; Tue, 25 May 2021 12:38:48 -0700 (PDT)
Received: from smtp.egensajt.se (smtp.egensajt.se [194.68.80.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8062F3A1ACA; Tue, 25 May 2021 12:38:48 -0700 (PDT)
Received: from [192.168.2.137] (h77-53-37-81.cust.a3fiber.se [77.53.37.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id A929B20F3A; Tue, 25 May 2021 21:38:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1621971525; bh=/NTM/N+cDd6olhED+eaRdJWSARjKojBxfp2Oh2f3q30=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=SUbESJULbsoreERXwBUE88n+PxWYvoxEorqNrVLomSETOjFx23+wf+a/E8H2qNono IhRG1fztV09/fkcLIOQH5CEtYTXHDdWCTfcb8scUBEEQYF+uquWHxsM7eERrrAVaPO viQfVmxap9j3oBRcbbQsqzu2StcpR66NjrHf4bq4=
To: Francesca Palombini , The IESG 
Cc: avtcore-chairs@ietf.org, draft-ietf-avtcore-multi-party-rtt-mix@ietf.org,  avt@ietf.org
References: <162137008198.8563.14104995910062091869@ietfa.amsl.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <488b81c7-8a5e-237b-d7ea-f7e63994cf05@ghaccess.se>
Date: Tue, 25 May 2021 21:38:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: <162137008198.8563.14104995910062091869@ietfa.amsl.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: sv
Archived-At: 
Subject: Re: [AVTCORE] Francesca Palombini's No Objection on draft-ietf-avtcore-multi-party-rtt-mix-18: (with COMMENT)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 May 2021 19:38:54 -0000

Francesca,

I am preparing a new version, with actions on your comments.

Den 2021-05-18 kl. 22:34, skrev Francesca Palombini via Datatracker:
> Francesca Palombini has entered the following ballot position for
> draft-ietf-avtcore-multi-party-rtt-mix-18: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for the work on this document. I have some minor non-blocking
> comments (feel free to take them or leave them), but I'd like some response to
> point 6. about the normative MUST.
>
> Francesca
>
> 1. -----
>
> FP: Please expand acronyms (CSRC, SDP, BOM, PSTN,...) on first use.
[GH] Done
>
> 2. -----
>
>        Since
>        simultaneous typing by more than two parties is very rare, this
>        method can be used successfully with good performance.  Recovery
>
> FP: I had question on this point, i.e. how was it evaluated that simultaneous
> typing by more than two parties is very rare, but that was answered in section
> 1.3 Intended application - so I would suggest adding a forward reference to
> that section in the paragraph quoted above.
[GH] Accepted.
>
> 3. -----
>
>     text stream using the RTP-mixer method.  The capability is indicated
>     by use of an SDP media attribute "rtt-mixer".
>
> FP: Please add a reference to RFC 8866.
[GH] Accepted
>
> 4. -----
>
>     streams in text format.  This is especially true if support of un-
>     encrypted SIP and media is supported because of lack of such support
>     in the target endpoints.  However, the mixing for conference-aware
>
> FP: I have a problem parsing this sentence "... if support ... is supported
> because of lack of such support"
[GH] Simplified wording applied
>
> 5. -----
>
>     is the timestamp of packet 102 THAT was received.  So B1 does not
>
> FP: nit - all capitals THAT.
[GH]Changed to lower case.
> 6. -----
>
>     the stream.  Some of them are optional.  Implementations MUST be able
>     to ignore optional control codes that they do not support.
>
> FP: I am really unsure how this MUST can be verified for interoperability.
> Maybe this does not need to be a BCP 14 MUST?
[GH] Changed as adviced by Spencer Dawkins and agreed by Francesca.
>
> 7. -----
>
>      |                                              | |
>      |(mix)[Bob)] Bob as well.                       | |
>
> FP: one space character too much
[GH] Done

Thanks,

Gunnar

>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt

-- 
Gunnar Hellstrm
GHAccess
gunnar.hellstrom@ghaccess.se


From nobody Tue May 25 12:58:00 2021
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0020E3A1B8F; Tue, 25 May 2021 12:57:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id codEsi3Tbb1t; Tue, 25 May 2021 12:57:54 -0700 (PDT)
Received: from smtp.egensajt.se (smtp.egensajt.se [194.68.80.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 066363A1B8C; Tue, 25 May 2021 12:57:53 -0700 (PDT)
Received: from [192.168.2.137] (h77-53-37-81.cust.a3fiber.se [77.53.37.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 9E82C2067A; Tue, 25 May 2021 21:57:51 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1621972671; bh=xf6E1aLNLnPEpUcAZOBK4RK2u/a07XzSqIJK+bSgoro=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Vfsi43E7MXAHk+LJzWhZ5wIcwaSGhpAhkbpeX0Ob2n+GjC8L+xKYzXsbxE5E0y/bG W+yJSNPXLI/Hk1HCd4s9AqbiQ4U3PKDDYVf9gLXs1sutwMSGjuhpIUs4acJGWLce5t SXX2EZOAfYiLbiasK0MvQ245o0a8c2DWcvCaLvxU=
To: Robert Wilton , The IESG 
Cc: draft-ietf-avtcore-multi-party-rtt-mix@ietf.org, avtcore-chairs@ietf.org,  avt@ietf.org, bernard.aboba@gmail.com
References: <162150064568.17183.13006538345122561644@ietfa.amsl.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: 
Date: Tue, 25 May 2021 21:57:49 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: <162150064568.17183.13006538345122561644@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: sv
Archived-At: 
Subject: Re: [AVTCORE] Robert Wilton's No Objection on draft-ietf-avtcore-multi-party-rtt-mix-18: (with COMMENT)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 May 2021 19:57:59 -0000

Robert,

Thanks for your review, please see answers inline.

Den 2021-05-20 kl. 10:50, skrev Robert Wilton via Datatracker:
> Robert Wilton has entered the following ballot position for
> draft-ietf-avtcore-multi-party-rtt-mix-18: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Hi,
>
> Thanks for this document.  This document is quite a long way from my core
> knowledge base, so I'm not sure whether there is much that I can really add.
> It doesn't seem to have any obvious manageability concerns.
>
> I was initially surprised by the capability exchange mechanism
> (offer/exchange), in that if both offeror and receiver could support multiple
> options then it is always the the receiver that decides which to use (by only
> selecting one).  I think that this is probably fine.  I don't know which
> parties generally initiate these exchanges, and whether there is ever a case
> where both offeror and receiver support multiple options where it would be
> beneficial for the offeror to make the final decision as to which should be
> used (e.g., when coordinating between more than two devices).
[GH] Since we do not currently have another multiparty method, it is 
hard to say if it would be suitable to answer that both are supported. 
It is a risk that allowing both simultaneously would cause confusion. 
Therefore I prefer to keep it as it is.
>
> As one minor nit, I would have preferred to see section 1.2, "Selected solution
> and considered alternatives" as an appendix.  I wasn't convinced that it is
> core to understanding this document, but I'm happy to leave it to the authors
> discretion as to whether they should move it, or leave it where it is.

[GH] You have a point in that view. However, another reviewer reported 
that it was very goog to find this information up-front. So, with some 
hesitation, I select to let the alternatives section stay where it is.


Thanks,

Gunnar

>
> Thanks,
> Rob
>
>
>
-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se


From nobody Tue May 25 13:42:34 2021
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB263A0874; Tue, 25 May 2021 13:42:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMBw81nZEKgn; Tue, 25 May 2021 13:42:28 -0700 (PDT)
Received: from smtp.egensajt.se (smtp.egensajt.se [194.68.80.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE50B3A0815; Tue, 25 May 2021 13:42:27 -0700 (PDT)
Received: from [192.168.2.137] (h77-53-37-81.cust.a3fiber.se [77.53.37.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 4039D209A0; Tue, 25 May 2021 22:42:23 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1621975343; bh=mmXI9n/XhcUJV/rtja2YZcszP2AOsMlpKcFmbCskYQk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Ep8h3GgLES90AcKxO4K8jBmgLa2mc2bDQk4bzaD2+aGNMEfyWCqKhMqiZ0k5PDzGZ oTKO9DeNj7lCZUTwvDLQfxNIheToc/au71LjTqr9ZL6/LYton6l83KSCXjpHRbmE5c RyItneVDS3Plaf5gMtNaj2+ef5I2IZ/RaSqBLZRM=
To: Roman Danyliw , The IESG 
Cc: draft-ietf-avtcore-multi-party-rtt-mix@ietf.org, avtcore-chairs@ietf.org,  avt@ietf.org, bernard.aboba@gmail.com
References: <162139124891.22846.16818872777832269848@ietfa.amsl.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <9e367a69-a035-cf03-5789-50f8c0cd4d33@ghaccess.se>
Date: Tue, 25 May 2021 22:42:20 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: <162139124891.22846.16818872777832269848@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: sv
Archived-At: 
Subject: Re: [AVTCORE] Roman Danyliw's No Objection on draft-ietf-avtcore-multi-party-rtt-mix-18: (with COMMENT)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 May 2021 20:42:33 -0000

Roman,

Thank you for the review,

please see answers inline,

Den 2021-05-19 kl. 04:27, skrev Roman Danyliw via Datatracker:
> Roman Danyliw has entered the following ballot position for
> draft-ietf-avtcore-multi-party-rtt-mix-18: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you to Rich Salz for the SECDIR review.
>
> ** Section 11.  Per “Participants with malicious intentions may appear ...”,
> this text seems to be describing an attacker that is party to the call.  If the
> mitigations suggested in the next sentence (i.e., secure signaling ... and
> authentication) aren’t present, this style of attack may also be possible by an
> on-path attacker as might be simple eavesdropping or injection of arbitrary
> content.
[GH] I added this sentence in section 11: "Care should be taken that if 
use of the mixer is allowed for users both with and without security 
procedures, opens for possible attacks by both unauthenticated call 
participants and even eavesdropping and manipulating of content 
non-participants."
>
> ** Section 11. Would the caution of the mixer not revealing that a user is
> hearing or speech impaired noted in Section 8 of RFC5194 apply here too?
[GH] Yes. How about inserting this sentence in section 8: " The services 
available through the RTT mixer may have special interest for deaf and 
hard-of-hearing persons. Some users may want to refrain from revealing 
such characteristics broadly in conferences. The design of the 
conference systems where the mixer is included MAY need to be made with 
confidentiality of such characteristics in mind."

Thanks,

Gunnar

>
-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se


From nobody Tue May 25 14:16:52 2021
Return-Path: 
X-Original-To: avt@ietf.org
Delivered-To: avt@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7486F3A0B8B; Tue, 25 May 2021 14:16:50 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: avt@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.30.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: avt@ietf.org
Message-ID: <162197741040.32300.3270882892009676075@ietfa.amsl.com>
Date: Tue, 25 May 2021 14:16:50 -0700
Archived-At: 
Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-multi-party-rtt-mix-19.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 May 2021 21:16:51 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Core Maintenance WG of the IETF.

        Title           : RTP-mixer formatting of multiparty Real-time text
        Author          : Gunnar Hellstrom
	Filename        : draft-ietf-avtcore-multi-party-rtt-mix-19.txt
	Pages           : 49
	Date            : 2021-05-25

Abstract:
   This document provides enhancements for RFC 4103 real-time text
   mixing suitable for a centralized conference model that enables
   source identification and rapidly interleaved transmission of text
   from different sources.  The intended use is for real-time text
   mixers and participant endpoints capable of providing an efficient
   presentation or other treatment of a multiparty real-time text
   session.  The specified mechanism builds on the standard use of the
   Contributing Source (CSRC) list in the Realtime Protocol (RTP) packet
   for source identification.  The method makes use of the same "text/
   t140" and "text/red" formats as for two-party sessions.

   Solutions using multiple RTP streams in the same RTP session are
   briefly mentioned, as they could have some benefits over the RTP-
   mixer model.  The possibility to implement the solution in a wide
   range of existing RTP implementations made the RTP-mixer model be
   selected to be fully specified in this document.

   A capability exchange is specified so that it can be verified that a
   mixer and a participant can handle the multiparty-coded real-time
   text stream using the RTP-mixer method.  The capability is indicated
   by use of an RFC 8866 Session Description Protocol (SDP) media
   attribute "rtt-mixer".

   The document updates RFC 4103 "RTP Payload for Text Conversation".

   A specification of how a mixer can format text for the case when the
   endpoint is not multiparty-aware is also provided.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-avtcore-multi-party-rtt-mix-19.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-multi-party-rtt-mix-19


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/



From nobody Tue May 25 14:23:38 2021
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7783A0BDE; Tue, 25 May 2021 14:23:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkcfeE72TCuP; Tue, 25 May 2021 14:23:32 -0700 (PDT)
Received: from smtp.egensajt.se (smtp.egensajt.se [194.68.80.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E13483A0BF3; Tue, 25 May 2021 14:23:31 -0700 (PDT)
Received: from [192.168.2.137] (h77-53-37-81.cust.a3fiber.se [77.53.37.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 13BDC2067A; Tue, 25 May 2021 23:23:30 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1621977810; bh=hwjNFvcNrSUzp2eJfp81uIJMbq7gJb/Z/OcQNNyJhc0=; h=Subject:From:To:Cc:References:Date:In-Reply-To:From; b=XuRJaT3XYqOCGrpoBihj6Gu8HGDkQRiaumaM+Cibp3HQzLXgRGd8q/5ihw5g77tyh HOiQiNBtiiayU1Ysutr+u6w5JeA8HM4URdg9tk9TRngeQHm/5ndJXN2bu0SgXmwlQu HqWCdbvQe6+INx4m8Hk+EF7nxRuztSkd4QfOGqF0=
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
To: Benjamin Kaduk , The IESG 
Cc: draft-ietf-avtcore-multi-party-rtt-mix@ietf.org, avtcore-chairs@ietf.org,  avt@ietf.org, bernard.aboba@gmail.com
References: <162139279927.706.12647899386073526674@ietfa.amsl.com> 
Message-ID: <4b23f984-d807-b0b0-d64b-edaa189f7cf4@ghaccess.se>
Date: Tue, 25 May 2021 23:23:27 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: sv
Archived-At: 
Subject: Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-ietf-avtcore-multi-party-rtt-mix-18: Version 19 submitted
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 May 2021 21:23:37 -0000

Anew version of the draft is published, intended to satisfy the DISCUSS 
and all comments.

A new version of I-D, draft-ietf-avtcore-multi-party-rtt-mix-19.txt
has been successfully submitted by Gunnar Hellstrom and posted to the
IETF repository.

Name:		draft-ietf-avtcore-multi-party-rtt-mix
Revision:	19
Title:		RTP-mixer formatting of multiparty Real-time text
Document date:	2021-05-25
Group:		avtcore
Pages:		49
URL:https://www.ietf.org/archive/id/draft-ietf-avtcore-multi-party-rtt-mix-19.txt
Status:https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/
Html:https://www.ietf.org/archive/id/draft-ietf-avtcore-multi-party-rtt-mix-19.html
Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-multi-party-rtt-mix
Diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-multi-party-rtt-mix-19


Regards

Gunnar


Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se


From nobody Tue May 25 17:23:45 2021
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A5F3A1514; Tue, 25 May 2021 17:23:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v_kXCeIdhK4d; Tue, 25 May 2021 17:23:36 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C2623A1516; Tue, 25 May 2021 17:23:36 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 14Q0NJp2014711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 May 2021 20:23:24 -0400
Date: Tue, 25 May 2021 17:23:19 -0700
From: Benjamin Kaduk 
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= 
Cc: The IESG , draft-ietf-avtcore-multi-party-rtt-mix@ietf.org,  avtcore-chairs@ietf.org, avt@ietf.org, bernard.aboba@gmail.com
Message-ID: <20210526002319.GD32395@kduck.mit.edu>
References: <162139279927.706.12647899386073526674@ietfa.amsl.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
Archived-At: 
Subject: Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-ietf-avtcore-multi-party-rtt-mix-18: Answer 4.
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 May 2021 00:23:40 -0000

Hi Gunnar,

On Tue, May 25, 2021 at 12:29:51PM +0200, Gunnar Hellstrm wrote:
> Benjamin,
> 
> Continuing the answers with the last part.,

Thank you for going through them all.  To be clear, I was not waiting for
you to finish before I started replying -- I just had a deadline earlier
today and did not have a chance to do much with my email sooner.  Having
the content chunked up into multiple pieces can make it easier to manage.

This is the only message I'm going to respond to, though, since I basically
have nothing further to say.  (I've already updated my ballot position to
remove the Discuss.)  I'm really impressed with how you took my comments
and turned them into improved text in the document, especially in the
places where I did not have a clear proposal.  I also appreciate your
explanations in the places where my questions did not make sense or are
already covered by some of the fundamental documents in this space; the
gaps in my knowledge are slowly getting filled in.

> Den 2021-05-19 kl. 04:53, skrev Benjamin Kaduk via Datatracker:
[...]
> [GH]Again, thanks for a thorough review and many good proposals for changes.

I must thank you again for your thorough responses; I feel like I am not
doing them justice by only sending this one short note, but do not want to
make you read through a repetitive set of "yes", "this sounds good", "thank
you", etc.

I read through the changes in the already-uploaded -19 (thank you again!),
and there were only two items that might be worth following up on (both in
section 3.16.3 of the -19):

You had proposed:

[GH] Would it be sufficient to insert the words "and reordering" in the
first two sentences in the paragraph to read: "The receiver SHALL monitor
the RTP sequence numbers of the received packets for gaps and packets
out of order.  If a sequence number gap appears and still exists after some
defined short time for jitter and reordering resolution, the packets in the
gap SHALL be regarded as lost."

I don't think this made it into the -19; my preference is to use your
proposed text that includes mention of reordering, but I do not insist on
it.


There was also a mention about the procedures for extracing T140blocks with
the redundancy procedure, where we currently say "T140blocks SHALL be
extracted in the following way.  The description is adapted to the default
redundancy case using the original and two redundant generations."  While I
am inclined to agree that the extension to the generic case with other
levels of redundancy is something that the reader can be expected to
perform, it feels a little incomplete to say that something "SHALL be
[done] in the following way" but give a not-complete/not-generic procedure.
Only for that reason do I prefer to have an explicit indication that the
procedure might need to be adjusted for a different level of redundancy; as
for the previous point, I do not insist on any change, though.

Thanks again,

Ben


From nobody Wed May 26 00:40:07 2021
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDCF3A24AE; Wed, 26 May 2021 00:40:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOvnHWVsDWAN; Wed, 26 May 2021 00:40:00 -0700 (PDT)
Received: from smtp.egensajt.se (smtp.egensajt.se [194.68.80.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2671A3A24AB; Wed, 26 May 2021 00:39:59 -0700 (PDT)
Received: from [192.168.2.137] (h77-53-37-81.cust.a3fiber.se [77.53.37.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 0D81020F41; Wed, 26 May 2021 09:39:56 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1622014796; bh=41sT6P0o1CZY16GF1kSdVrSGzLgFHDViOTuNVBoPJCI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=W9Fzy9UMtPxSQPJtqHgbhR9BYVv+UUNPtwG/ab/7Ywjw8h3tWCVVSv2g6knWqerMY EGY0lRoMP3sg1R8ndHXmiC2DwcVBrsoXIZS2m9K3+PgX/haE2gz2HkmGNrkcFMI6Tl SJBMkyBfjg/cJs2m7VPemjF/iF+jopqz+bXnCNLw=
To: Benjamin Kaduk 
Cc: The IESG , draft-ietf-avtcore-multi-party-rtt-mix@ietf.org, avtcore-chairs@ietf.org, avt@ietf.org, bernard.aboba@gmail.com
References: <162139279927.706.12647899386073526674@ietfa.amsl.com>  <20210526002319.GD32395@kduck.mit.edu>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <22fd1d92-b924-9391-d34a-2a31c2e7d035@ghaccess.se>
Date: Wed, 26 May 2021 09:39:53 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: <20210526002319.GD32395@kduck.mit.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: sv
Archived-At: 
Subject: Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-ietf-avtcore-multi-party-rtt-mix-18: Answer 4.
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 May 2021 07:40:06 -0000

Hi Ben,

Thank you for the kind words.

The inserted words about packets out-of-order that you did not find in 
version -19 are there, but in the beginning of section 3.16.2, instead 
of in 3.16.3 where you expected to find them.

Please see furthe comments inline.

Den 2021-05-26 kl. 02:23, skrev Benjamin Kaduk:
> Hi Gunnar,
>
> On Tue, May 25, 2021 at 12:29:51PM +0200, Gunnar Hellstrm wrote:
>> Benjamin,
>>
>> Continuing the answers with the last part.,
> Thank you for going through them all.  To be clear, I was not waiting for
> you to finish before I started replying -- I just had a deadline earlier
> today and did not have a chance to do much with my email sooner.  Having
> the content chunked up into multiple pieces can make it easier to manage.
>
> This is the only message I'm going to respond to, though, since I basically
> have nothing further to say.  (I've already updated my ballot position to
> remove the Discuss.)  I'm really impressed with how you took my comments
> and turned them into improved text in the document, especially in the
> places where I did not have a clear proposal.  I also appreciate your
> explanations in the places where my questions did not make sense or are
> already covered by some of the fundamental documents in this space; the
> gaps in my knowledge are slowly getting filled in.
>
>> Den 2021-05-19 kl. 04:53, skrev Benjamin Kaduk via Datatracker:
> [...]
>> [GH]Again, thanks for a thorough review and many good proposals for changes.
> I must thank you again for your thorough responses; I feel like I am not
> doing them justice by only sending this one short note, but do not want to
> make you read through a repetitive set of "yes", "this sounds good", "thank
> you", etc.
>
> I read through the changes in the already-uploaded -19 (thank you again!),
> and there were only two items that might be worth following up on (both in
> section 3.16.3 of the -19):
>
> You had proposed:
>
> [GH] Would it be sufficient to insert the words "and reordering" in the
> first two sentences in the paragraph to read: "The receiver SHALL monitor
> the RTP sequence numbers of the received packets for gaps and packets
> out of order.  If a sequence number gap appears and still exists after some
> defined short time for jitter and reordering resolution, the packets in the
> gap SHALL be regarded as lost."
>
> I don't think this made it into the -19; my preference is to use your
> proposed text that includes mention of reordering, but I do not insist on
> it.

[GH] They are there, in 3.16.2, where basic packet reception and gap 
analysis is specified.

it says:

" The receiver SHALL monitor the RTP sequence numbers of the received
  packets for gaps and packets out of order. If a sequence number gap
  appears and still exists after some defined short time for jitter and
  reordering resolution, the packets in the gap SHALL be regarded as
  lost. "

This is intended to require that packets are in order when they go to 
the loss analysis and data retrieval stages.

Very late packets out-of-order would be regarded lost. When you said 
that you could imagine cases of duplication, did you then imagine a 
procedure which would recover text also from late coming packets after 
the short time mentioned in the paragraph above? It would be possible, 
but I do not think it should be part of the general document, because it 
would possibly mean manipulating display buffers already presenting 
earlier received text.

I have created a paragraph for that, that can follow the first in 
3.16.2, but I do not think it adds any value to insert it. What do you 
think?

" Advanced procedures for recovering data from packets received out of
  order later than the short time for jitter and reordering resolution
  mentioned above MAY be implemented but are out of scope for this 
document.
  Such procedures would need to manipulate data in receive buffers and
  possibly also in presentation areas. The procedures MUST avoid
  duplication of already received data."

>
> There was also a mention about the procedures for extracing T140blocks with
> the redundancy procedure, where we currently say "T140blocks SHALL be
> extracted in the following way.  The description is adapted to the default
> redundancy case using the original and two redundant generations."  While I
> am inclined to agree that the extension to the generic case with other
> levels of redundancy is something that the reader can be expected to
> perform, it feels a little incomplete to say that something "SHALL be
> [done] in the following way" but give a not-complete/not-generic procedure.
> Only for that reason do I prefer to have an explicit indication that the
> procedure might need to be adjusted for a different level of redundancy; as
> for the previous point, I do not insist on any change, though.

[GH] I have made a try to generalize the description. I think it can 
replace the current limited one. What do you think?

"
3.16.3. Extracting text and handling recovery

  When applying the following procedures, the effects MUST be
  considered of possible timestamp wrap around and the RTP session
  possibly changing SSRC.

  When a packet is received in an RTP session using the packetization
  for multiparty-aware endpoints, its T140blocks SHALL be extracted in
  the following way.

  The source SHALL be extracted from the CSRC-list if available,
  otherwise from the SSRC.

  If the received packet is the first packet received from the source,
  then all T140blocks in the packet SHALL be retrieved and assigned to
  a receive buffer for the source beginning with the oldest available
  redundant generation, continuing with the younger redundant generations
  in age order and finally the primary.

  NOTE: The normal case is that in the first packet, only the primary
  data has contents. The redundant data has contents in the first
  received packet from a source only after initial packet loss.

  If the packet is not the first packet from a source, then if redundant
  data is available, the process SHALL start with the oldest generation.
  The timestamp of that redundant data SHALL be
  created by subtracting its timestamp offset from the RTP timestamp.
  If the resulting timestamp is later than the latest retrieved data
  from the same source, then the redundant data SHALL be retrieved and
  appended to the receive buffer. The process SHALL be continued in
  the same way for all younger generations of redundant data. After that,
  the timestamp of the packet SHALL be compared with the timestamp of
  the latest retrieved data from the same source and if it is later,
  then the primary data SHALL be retrieved from the packet and appended
  to the receive buffer for the source.

"

Regards

Gunnar

>
> Thanks again,
>
> Ben

-- 
Gunnar Hellstrm
GHAccess
gunnar.hellstrom@ghaccess.se


From nobody Wed May 26 01:25:36 2021
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65EF63A260D for ; Wed, 26 May 2021 01:25:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIg2mkMEs-r9 for ; Wed, 26 May 2021 01:25:31 -0700 (PDT)
Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79E3A3A260F for ; Wed, 26 May 2021 01:25:31 -0700 (PDT)
Received: by mail-vs1-xe35.google.com with SMTP id x22so292726vsn.2 for ; Wed, 26 May 2021 01:25:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=wwYmdOz8CRJ/QFlIIDp9y6bPd6CtwMoUpWyd+tRw4yQ=; b=MrelNltWW2MQzOFByhjVHBA/2fSzez4jssfHbIrlxq7bKYIsJB9UlJiVmrltip/2T6 UZVpsCSDIaQWWJK/nNxNTTzTm/FAqIjFZ7PtkevX11AUpm2mYcNxXmzqb/n3rP92cp/9 u/AwT4b7xaeQy8dawh4fwyoUOqgPXdeMmF5QOusQOiPxHBuxnd4vg+mk4t7eten5mRwq 9GmhgKvJosUNnd05BjysnzMfwYJKM7pcTS9swTSfnvN6ncjLnoe5jST6rMuSKAXaA8YF 4rxpZrAepTkH5PRt3OTFxJWKvSA34Mpj1s+f6k4hFo8e3yViOEyNZCNKv3EmZKTBEqfo OT7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=wwYmdOz8CRJ/QFlIIDp9y6bPd6CtwMoUpWyd+tRw4yQ=; b=c5U2B9Usgqdwi+aN1uhPgSZ69gexNF9H/7Y/TYLSFJs11dYzHb3hwiMu5vzZpvJQwa +QmssK0QxBM/xLmnf214koBX2D70ZLAtKCVi7RqVLvJ48RSbbNn4NvaUulow2NRHAiwf MmySwYxNGT/mvRujMmbwWgyBXyH2kgtegjpl2/P4PBGGWlCZg8mvVO0OCXt2MpyQ2TCu 8JwZ9pLmGegOObJek4rM0dwt8wau/boM1E4QLWeJGiyHTckzu/NnSgQdO8IK20RkDDav 0pmnjmEphcpDK2FD4ErkG1bVdFb9+E4wfQOUewdo2eAC9631a/w/1dbhRiqRUAv7nXLH g79Q==
X-Gm-Message-State: AOAM530113ADnJGUqk8CEs/bzb7JZVJrEUVo27KZvaaRB1xiq4zhYXUJ z+opiHWVqZB463RiOY/UKIF8TRuoQJ1mwV/aU2D/9yT53ic=
X-Google-Smtp-Source: ABdhPJysBXumDMkpdDQYdPex1VRrRgtuB4d0AwZ2xeICMOSx86lPrImwB20iR1IeJ8YQJaDPhak9tD+pW+4FKUg8QWc=
X-Received: by 2002:a67:ebd7:: with SMTP id y23mr29332144vso.54.1622017529446;  Wed, 26 May 2021 01:25:29 -0700 (PDT)
MIME-Version: 1.0
From: "Murray S. Kucherawy" 
Date: Wed, 26 May 2021 01:25:16 -0700
Message-ID: 
To: IETF AVTCore WG 
Content-Type: multipart/alternative; boundary="000000000000a9869805c337623a"
Archived-At: 
Subject: [AVTCORE] draft-ietf-avtcore-multi-party-rtt-mix ready?
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 May 2021 08:25:35 -0000

--000000000000a9869805c337623a
Content-Type: text/plain; charset="UTF-8"

Just checking in: Did version -19 of this draft include all pending edits
after IESG Evaluation?  That is, is it ready to advance to the RFC Editor?

The DISCUSS has been cleared, but there were other comments that had drawn
replies, so I wanted to check before pushing the magic buttons.

Thanks,
-MSK

--000000000000a9869805c337623a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Just checking in: Did version -19 of this draft inclu=
de all pending edits after IESG Evaluation?=C2=A0 That is, is it ready to a=
dvance to the RFC Editor?

The DISCUSS has been cle=
ared, but there were other comments that had drawn replies, so I wanted to =
check before pushing the magic buttons.

Thanks,
-MSK



--000000000000a9869805c337623a--


From nobody Wed May 26 03:14:32 2021
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D44B3A291A for ; Wed, 26 May 2021 03:14:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxTCmOTrbF7e for ; Wed, 26 May 2021 03:14:26 -0700 (PDT)
Received: from smtp.egensajt.se (smtp.egensajt.se [194.68.80.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7893A3A2916 for ; Wed, 26 May 2021 03:14:25 -0700 (PDT)
Received: from [192.168.2.137] (h77-53-37-81.cust.a3fiber.se [77.53.37.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 352DC20FC9 for ; Wed, 26 May 2021 12:14:22 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1622024062; bh=3+rNWTe/whaBznMCVy3ARQGr5Ivz1k5C++hjO7OW+hQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=PjOiUU9a5Ac2MRcKVT0DkzTBH22e4Y1fjdk+StEdVO+OQXLwQCyhbDI8J83Ee2rXR uyn3VtU3xHqOYgAgPL6/Xj+y+JwvhOtBkzJH0+pbQi/UjWm7PZ4A524uA4haem7gvy A4ZibNphGXVwZmV1hC6jNeLwxhXxQ3DrqHdGeL+I=
To: avt@ietf.org
References: 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <0cea2392-befd-1d6c-3949-2289cc740d96@ghaccess.se>
Date: Wed, 26 May 2021 12:14:21 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------8A3D856CE695BB0435268FA1"
Content-Language: sv
Archived-At: 
Subject: Re: [AVTCORE] draft-ietf-avtcore-multi-party-rtt-mix ready?
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 May 2021 10:14:31 -0000

This is a multi-part message in MIME format.
--------------8A3D856CE695BB0435268FA1
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Thanks for checking.

In a response to Ben this morning, I proposed wording for section 3.16.3 
to make it general for any level of redundancy. I believe that that is a 
good improvement, so I want to make a version -20.

I also want to include some acknowledgements. But that may be possible 
later.(?)

Thanks,

Gunnar

Den 2021-05-26 kl. 10:25, skrev Murray S. Kucherawy:
> Just checking in: Did version -19 of this draft include all pending 
> edits after IESG Evaluation?  That is, is it ready to advance to the 
> RFC Editor?
>
> The DISCUSS has been cleared, but there were other comments that had 
> drawn replies, so I wanted to check before pushing the magic buttons.
>
> Thanks,
> -MSK
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt

-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se


--------------8A3D856CE695BB0435268FA1
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Thanks for checking.

    
In a response to Ben this morning, I proposed wording for section
      3.16.3 to make it general for any level of redundancy. I believe
      that that is a good improvement, so I want to make a version -20.
      

    

    
I also want to include some acknowledgements. But that may be
      possible later.(?)

    

    
Thanks,

    
Gunnar

    

    
Den 2021-05-26 kl. 10:25, skrev Murray
      S. Kucherawy:

    

    

      
      

        
Just checking in: Did version -19 of this draft include all
          pending edits after IESG Evaluation?  That is, is it ready to
          advance to the RFC Editor?

        


        

        
The DISCUSS has been cleared, but there were other comments
          that had drawn replies, so I wanted to check before pushing
          the magic buttons.

        


        

        
Thanks,

        
-MSK

        

        

      

      

      

      
_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt


    

    
-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se

  


--------------8A3D856CE695BB0435268FA1--


From nobody Wed May 26 08:07:56 2021
Return-Path: 
X-Original-To: avt@ietf.org
Delivered-To: avt@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D5C3A316A; Wed, 26 May 2021 08:07:54 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: avt@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.30.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: avt@ietf.org
Message-ID: <162204167425.27410.6248256018737462582@ietfa.amsl.com>
Date: Wed, 26 May 2021 08:07:54 -0700
Archived-At: 
Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-multi-party-rtt-mix-20.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 May 2021 15:07:54 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Core Maintenance WG of the IETF.

        Title           : RTP-mixer formatting of multiparty Real-time text
        Author          : Gunnar Hellstrom
	Filename        : draft-ietf-avtcore-multi-party-rtt-mix-20.txt
	Pages           : 50
	Date            : 2021-05-26

Abstract:
   This document provides enhancements for RFC 4103 real-time text
   mixing suitable for a centralized conference model that enables
   source identification and rapidly interleaved transmission of text
   from different sources.  The intended use is for real-time text
   mixers and participant endpoints capable of providing an efficient
   presentation or other treatment of a multiparty real-time text
   session.  The specified mechanism builds on the standard use of the
   Contributing Source (CSRC) list in the Realtime Protocol (RTP) packet
   for source identification.  The method makes use of the same "text/
   t140" and "text/red" formats as for two-party sessions.

   Solutions using multiple RTP streams in the same RTP session are
   briefly mentioned, as they could have some benefits over the RTP-
   mixer model.  The possibility to implement the solution in a wide
   range of existing RTP implementations made the RTP-mixer model be
   selected to be fully specified in this document.

   A capability exchange is specified so that it can be verified that a
   mixer and a participant can handle the multiparty-coded real-time
   text stream using the RTP-mixer method.  The capability is indicated
   by use of an RFC 8866 Session Description Protocol (SDP) media
   attribute "rtt-mixer".

   The document updates RFC 4103 "RTP Payload for Text Conversation".

   A specification of how a mixer can format text for the case when the
   endpoint is not multiparty-aware is also provided.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-avtcore-multi-party-rtt-mix-20.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-multi-party-rtt-mix-20


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/



From nobody Wed May 26 08:09:05 2021
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662283A3171 for ; Wed, 26 May 2021 08:09:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ns2VJ3apAJdU for ; Wed, 26 May 2021 08:08:57 -0700 (PDT)
Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 989CE3A316E for ; Wed, 26 May 2021 08:08:51 -0700 (PDT)
Received: by mail-ua1-x92a.google.com with SMTP id h26so942846uab.13 for ; Wed, 26 May 2021 08:08:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MD1M9zXRXkTwGCzmAnRruBPqeid90Kbjp4lLKwdO4OI=; b=j88Mh1kjJHixZtoBX4UNrRcIDNvMezEV853IN3QysVE0q6rWPePiLyT7QA9v6Cguv/ gdcXK6AbgVnLL1IPii5d3CipF3vKcytJwNMBpsNVzJMqx5fNTt3pQTzOmah+PZD6H5+n lcQ9z8TYmipqloyVtZ5chZLDuGFrP9PKRS6AZOD+1IxVnmh3XISp0LSBB43deE4Qoq2q yD6eCVZE/bB/zdqTOb241EbO3znq+RuNPPjcVzn4acY1Pwjw137Aci1xzccpFVYPaw7n 4BjIkwoUm/daFqjeO2QX7zieah2ChvKHY+LvNFY4cQO56bLCcX97mpX2w1FChBejvyQz IDIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MD1M9zXRXkTwGCzmAnRruBPqeid90Kbjp4lLKwdO4OI=; b=hLP4gPhLwcC/lqlpqpQBL/3FLIxK54LNmYN6qIIR4Pflki2nwB9/Gut0dUDCfOKw+h ygsdQCeHQ49yIm6XPiL9dy9M6tShgl8WPIpExNykIkLFqxLcRsH75ed9DANcKgUsC4Hd SAkWTxojGXCmrRK6lTxiGpeDJFTUEhqeN6eTsYrKqG8qlXrxbYSsww+guVAMxFhybOxM ahjKHx8wMek9fOoYitDS2ucHuekUJonJ5E2FoocrQjDUpcrwxTgR/OivKe7Vu7FwRD3l mHXmbU6R9mVzvYuzCsxPni4wpScM8Qmyu+XBIpiI1QUqC2i//wrPOsQzr4XySWg9Blbm s0Kg==
X-Gm-Message-State: AOAM531xk96QDimLS+RltL94mkMTflQ1hsFkViia73kvJzBBaScjvAIs IvGBQJbuuqco3EsXJuMfwD/IcXIH8xfKydnTEysIGSvccyU=
X-Google-Smtp-Source: ABdhPJzNFznlk+LdjjLnEqxHBQcNFjaZnlIgmhHjVN2JtbTqLv0w5f0l9SvPc7/ecDoWfyiqpz1G4VP0hb7uyQjfMpY=
X-Received: by 2002:ab0:3256:: with SMTP id r22mr32731193uan.47.1622041729547;  Wed, 26 May 2021 08:08:49 -0700 (PDT)
MIME-Version: 1.0
References:  <0cea2392-befd-1d6c-3949-2289cc740d96@ghaccess.se>
In-Reply-To: <0cea2392-befd-1d6c-3949-2289cc740d96@ghaccess.se>
From: "Murray S. Kucherawy" 
Date: Wed, 26 May 2021 08:08:35 -0700
Message-ID: 
To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= 
Cc: IETF AVTCore WG 
Content-Type: multipart/alternative; boundary="00000000000019c6c805c33d05b9"
Archived-At: 
Subject: Re: [AVTCORE] draft-ietf-avtcore-multi-party-rtt-mix ready?
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 May 2021 15:09:02 -0000

--00000000000019c6c805c33d05b9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, May 26, 2021 at 3:14 AM Gunnar Hellstr=C3=B6m <
gunnar.hellstrom@ghaccess.se> wrote:

> Thanks for checking.
>
> In a response to Ben this morning, I proposed wording for section 3.16.3
> to make it general for any level of redundancy. I believe that that is a
> good improvement, so I want to make a version -20.
>
> I also want to include some acknowledgements. But that may be possible
> later.(?)
>

I'm fine with tweaks to Acknowledgements during AUTH48 if you want to make
them that late, but if you know what changes you want to make now, you can
just include them in -20.

Either way I'll mark -19 as "Revised I-D Needed", and it'll revert to me
when you post -20.

Thanks for the update.


-MSK

--00000000000019c6c805c33d05b9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Wed, May 26, 2021 at 3:14 AM Gunnar He=
llstr=C3=B6m <gunnar.hel=
lstrom@ghaccess.se> wrote:

 =20
   =20
 =20
  

    
Thanks for checking.

    
In a response to Ben this morning, I proposed wording for section
      3.16.3 to make it general for any level of redundancy. I believe
      that that is a good improvement, so I want to make a version -20.
      

    

    
I also want to include some acknowledgements. But that may be
      possible later.(?)

    

I'm fine with tweaks to =
Acknowledgements during AUTH48 if you want to make them that late, but if y=
ou know what changes you want to make now, you can just include them in -20=
.

Either way I'll mark -19 as "Revised I-=
D Needed", and it'll revert to me when you post -20.
Thanks for the update.


=
-MSK


--00000000000019c6c805c33d05b9--


From nobody Wed May 26 08:12:27 2021
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B623A3149 for ; Wed, 26 May 2021 08:12:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHDYj6nsRrcF for ; Wed, 26 May 2021 08:11:55 -0700 (PDT)
Received: from smtp.egensajt.se (smtp.egensajt.se [194.68.80.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EE363A0DFB for ; Wed, 26 May 2021 08:11:55 -0700 (PDT)
Received: from [192.168.2.137] (h77-53-37-81.cust.a3fiber.se [77.53.37.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 25F2620CC7; Wed, 26 May 2021 17:11:52 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1622041912; bh=rcq1Q4TA5E7FHKzScC5lLk9KMsjPXDDn6te4at0pQFs=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=XosoUWA41b0pdxoZ/fDourOXuvecM46o9Nhg0S4VoEim09LDnR5aEUKV/LF0yNLFb wcF1bKQlSDEKryDUyikBgaD4YkcLeogqJlZU5hb39OXE1Y/L7GFVlmPGln0epIcaps UIAudevKR/yegay12KICwMMutm1DRt515vYAu/E4=
To: "Murray S. Kucherawy" 
Cc: IETF AVTCore WG 
References:  <0cea2392-befd-1d6c-3949-2289cc740d96@ghaccess.se> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <956d39a6-4d0c-0af0-9d42-04d09cc9417f@ghaccess.se>
Date: Wed, 26 May 2021 17:11:50 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------11A4CD8B5E4CC2B81D4AB8EB"
Content-Language: sv
Archived-At: 
Subject: Re: [AVTCORE] draft-ietf-avtcore-multi-party-rtt-mix ready?
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 May 2021 15:12:00 -0000

This is a multi-part message in MIME format.
--------------11A4CD8B5E4CC2B81D4AB8EB
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Murray,

-20 is just submitted with generalized retrieval procedure and full 
acknowledgement section.

Thanks,

Gunnar

Den 2021-05-26 kl. 17:08, skrev Murray S. Kucherawy:
> On Wed, May 26, 2021 at 3:14 AM Gunnar Hellström 
> > 
> wrote:
>
>     Thanks for checking.
>
>     In a response to Ben this morning, I proposed wording for section
>     3.16.3 to make it general for any level of redundancy. I believe
>     that that is a good improvement, so I want to make a version -20.
>
>     I also want to include some acknowledgements. But that may be
>     possible later.(?)
>
>
> I'm fine with tweaks to Acknowledgements during AUTH48 if you want to 
> make them that late, but if you know what changes you want to make 
> now, you can just include them in -20.
>
> Either way I'll mark -19 as "Revised I-D Needed", and it'll revert to 
> me when you post -20.
>
> Thanks for the update.
>
>
> -MSK

-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se


--------------11A4CD8B5E4CC2B81D4AB8EB
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Murray,

    

    
-20 is just submitted with generalized retrieval procedure and
      full acknowledgement section.

    
Thanks,

    
Gunnar

    

    
Den 2021-05-26 kl. 17:08, skrev Murray
      S. Kucherawy:

    

    

      
      

        
On Wed, May 26, 2021 at 3:14 AM Gunnar Hellström
          <gunnar.hellstrom@ghaccess.se>
          wrote:

        

        

          

            

              
Thanks for checking.

              
In a response to Ben this morning, I proposed wording
                for section 3.16.3 to make it general for any level of
                redundancy. I believe that that is a good improvement,
                so I want to make a version -20. 

              

              
I also want to include some acknowledgements. But that
                may be possible later.(?)

              

            

          

          


          

          
I'm fine with tweaks to Acknowledgements during AUTH48 if
            you want to make them that late, but if you know what
            changes you want to make now, you can just include them in
            -20.

          


          

          
Either way I'll mark -19 as "Revised I-D Needed", and
            it'll revert to me when you post -20.

          


          

          
Thanks for the update.

          


          

          


          

          
-MSK

          

        

      

    

    
-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se

  


--------------11A4CD8B5E4CC2B81D4AB8EB--


From nobody Wed May 26 08:17:29 2021
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C003A31BB for ; Wed, 26 May 2021 08:17:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bx8AkwYOYRab for ; Wed, 26 May 2021 08:17:22 -0700 (PDT)
Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 951B23A31B0 for ; Wed, 26 May 2021 08:17:22 -0700 (PDT)
Received: by mail-ua1-x936.google.com with SMTP id f1so965458uaj.10 for ; Wed, 26 May 2021 08:17:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g81ebUXw97FxNCR4RBuuUw2aDp38pdpjBQv0HOSkLPg=; b=TL5MivKrYsudsCxUrXsezLeyV2BqlGQhLnzQA4xaGjhbtSw4k/si1/w1bEXykZnntu 46s2vrGzPiloGoP96MPD1x5/ctbnIhADK2YM0y5WtMdzbk4y8+WwsVp5cyOoEa/B8e5T YEZIvb81FK0pSSfBKxByKjX2v1dRIFvnq147VGt/sKS9KYDL3ou2VUg6YhAhNA8EqdvJ JOp0KTryMa20n90UKrnPg+ZuajMp7s4VH9Ig6po8QwGDHDxgBAAFiAQt9oXhT9rEhLdO Hry3HLPK+mM7QkdfPvfxl5mESRRQacT52staGxz+f/2FnTU4lUfR8RJwWBQIVPktV6a6 EdaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=g81ebUXw97FxNCR4RBuuUw2aDp38pdpjBQv0HOSkLPg=; b=sG/Rd5PCu2Xo/Ddv9Lp/nenJMlMbDFDBj0JUeqL5sfYtsJ932MM6y7nOuBCvX1AQp1 bBfMZPwjD+Y8UGFR9GAvhgANtOx/Owv0ZBC7f+GHBy7qTQsMFhmkqXFvJSHtyh14wr06 QNF4mXyZZk2shTaeLf4LXu3zG5kfU8euiI1qtB8V2Y4pQZAYe2NkMErnxqoB9OpB2FTu uIhcib7yVBZSmZSc5UxY55JG8PDKgnTQ2OZBakcsDbBy73aPV9lVtoMSF1uKREk2dXsR GDC5roZdTGbDVPWPzhPR1EvYqscsaafo8tN/AC0onRzhdGobN+B/jG0f8iSsoAHrxlhX fPuw==
X-Gm-Message-State: AOAM530Zq33S2M4NEaMdu8db8ysZBVTz+jdqgQ2hL6e6rnhrzY6jYsuu dx50zdhtyRUwO1pRxbSua/D5lPqUA5Cm5l0FlUU=
X-Google-Smtp-Source: ABdhPJww27ABsStE+Gh051VVYjI3/dNbmtiWCFtMQea7077tlXUMYwcfBE+8GGTsW1ELKtDFiP5vGJT62Wo6p8sBU6k=
X-Received: by 2002:ab0:390a:: with SMTP id b10mr1173547uaw.76.1622042240182;  Wed, 26 May 2021 08:17:20 -0700 (PDT)
MIME-Version: 1.0
References:  <0cea2392-befd-1d6c-3949-2289cc740d96@ghaccess.se>  <956d39a6-4d0c-0af0-9d42-04d09cc9417f@ghaccess.se>
In-Reply-To: <956d39a6-4d0c-0af0-9d42-04d09cc9417f@ghaccess.se>
From: "Murray S. Kucherawy" 
Date: Wed, 26 May 2021 08:17:06 -0700
Message-ID: 
To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= 
Cc: IETF AVTCore WG 
Content-Type: multipart/alternative; boundary="000000000000896e4005c33d2366"
Archived-At: 
Subject: Re: [AVTCORE] draft-ietf-avtcore-multi-party-rtt-mix ready?
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 May 2021 15:17:28 -0000

--000000000000896e4005c33d2366
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Yup, I saw that shortly after I sent my last message.  Serves me right for
not checking.

-20 is approved for publication.  You should get the announcement within
the next several days.

-MSK

On Wed, May 26, 2021 at 8:11 AM Gunnar Hellstr=C3=B6m <
gunnar.hellstrom@ghaccess.se> wrote:

> Murray,
>
> -20 is just submitted with generalized retrieval procedure and full
> acknowledgement section.
>
> Thanks,
>
> Gunnar
> Den 2021-05-26 kl. 17:08, skrev Murray S. Kucherawy:
>
> On Wed, May 26, 2021 at 3:14 AM Gunnar Hellstr=C3=B6m <
> gunnar.hellstrom@ghaccess.se> wrote:
>
>> Thanks for checking.
>>
>> In a response to Ben this morning, I proposed wording for section 3.16.3
>> to make it general for any level of redundancy. I believe that that is a
>> good improvement, so I want to make a version -20.
>>
>> I also want to include some acknowledgements. But that may be possible
>> later.(?)
>>
>
> I'm fine with tweaks to Acknowledgements during AUTH48 if you want to mak=
e
> them that late, but if you know what changes you want to make now, you ca=
n
> just include them in -20.
>
> Either way I'll mark -19 as "Revised I-D Needed", and it'll revert to me
> when you post -20.
>
> Thanks for the update.
>
>
> -MSK
>
> --
> Gunnar Hellstr=C3=B6m
> GHAccessgunnar.hellstrom@ghaccess.se
>
>

--000000000000896e4005c33d2366
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Yup, I saw that shortly after I sent my last message.=
=C2=A0 Serves me right for not checking.

-20 is ap=
proved for publication.=C2=A0 You should get the announcement within the ne=
xt several days.

-MSK

On Wed, May 26, 202=
1 at 8:11 AM Gunnar Hellstr=C3=B6m <gunnar.hellstrom@ghaccess.se> wrote:

 =20
   =20
 =20
  

    
Murray,

    

    
-20 is just submitted with generalized retrieval procedure and
      full acknowledgement section.

    
Thanks,

    
Gunnar

    

    
Den 2021-05-26 kl. 17:08, skrev Murray
      S. Kucherawy:

    

    

     =20
      

        
On Wed, May 26, 2021 at 3:14 AM Gunnar Hellstr=C3=
=B6m
          <gunnar.hellstrom@ghaccess.se>
          wrote:

        

        

          

            

              
Thanks for checking.

              
In a response to Ben this morning, I proposed wording
                for section 3.16.3 to make it general for any level of
                redundancy. I believe that that is a good improvement,
                so I want to make a version -20. 

              

              
I also want to include some acknowledgements. But that
                may be possible later.(?)

              

            

          

          


          

          
I'm fine with tweaks to Acknowledgements during AUTH48 i=
f
            you want to make them that late, but if you know what
            changes you want to make now, you can just include them in
            -20.

          


          

          
Either way I'll mark -19 as "Revised I-D Needed&quo=
t;, and
            it'll revert to me when you post -20.

          


          

          
Thanks for the update.

          


          

          


          

          
-MSK

          

        

      

    

    
--=20
Gunnar Hellstr=C3=B6m
GHAccess
gunnar.he=
llstrom@ghaccess.se

  





--000000000000896e4005c33d2366--


From nobody Wed May 26 08:25:12 2021
Return-Path: 
X-Original-To: avt@ietf.org
Delivered-To: avt@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F583A31F1; Wed, 26 May 2021 08:25:10 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 7.30.0
Auto-Submitted: auto-generated
Precedence: bulk
Cc: The IESG , avt@ietf.org, avtcore-chairs@ietf.org, bernard.aboba@gmail.com, draft-ietf-avtcore-multi-party-rtt-mix@ietf.org, rfc-editor@rfc-editor.org, superuser@gmail.com
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <162204271050.27280.561200875302525148@ietfa.amsl.com>
Date: Wed, 26 May 2021 08:25:10 -0700
Archived-At: 
Subject: [AVTCORE] Protocol Action: 'RTP-mixer formatting of multiparty Real-time text' to Proposed Standard (draft-ietf-avtcore-multi-party-rtt-mix-20.txt)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 May 2021 15:25:11 -0000

The IESG has approved the following document:
- 'RTP-mixer formatting of multiparty Real-time text'
  (draft-ietf-avtcore-multi-party-rtt-mix-20.txt) as Proposed Standard

This document is the product of the Audio/Video Transport Core Maintenance
Working Group.

The IESG contact persons are Murray Kucherawy and Francesca Palombini.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/




Technical Summary:

   Enhancements for RFC 4103 real-time text mixing are provided in this
   document, suitable for a centralized conference model that enables
   source identification and rapidly interleaved transmission of text
   from different sources.  The intended use is for real-time text
   mixers and participant endpoints capable of providing an efficient
   presentation or other treatment of a multi-party real-time text
   session.  The specified mechanism builds on the standard use of the
   CSRC list in the RTP packet for source identification.  The method
   makes use of the same "text/t140" and "text/red" formats as for two-
   party sessions.

   Solutions using multiple RTP streams in the same RTP session are
   briefly mentioned, as they could have some benefits over the RTP-
   mixer model.  The possibility to implement the solution in a wide
   range of existing RTP implementations made the RTP-mixer model be
   selected to be fully specified in this document.

   A capability exchange is specified so that it can be verified that a
   mixer and a participant can handle the multi-party coded real-time
   text stream using the RTP-mixer method.  The capability is indicated
   by use of an SDP media attribute "rtt-mixer".

   The document updates RFC 4103 "RTP Payload for Text Conversation".

   A specification of how a mixer can format text for the case when the
   endpoint is not multi-party aware is also provided.

Working Group Summary:

WG Last Call of "RTP-mixer formatting of multi-party Real-time text" was
announced on November 25, 2020:
https://mailarchive.ietf.org/arch/msg/avt/tjGlWlXL5a54nhgl5nRV3jkD_tk/

WGLC concluded on December 9, 2020.

Of the 6 participants responding to the WGLC, 3 supported Advancement to
Proposed Standard, and 3 respondents provided comments, which were addressed
by the author. 

Document Quality:
There are no existing implementations of the specification.  

Personnel:

Document Shepherd is Bernard Aboba. Responsible AD is Murray Kucherawy.


From nobody Wed May 26 09:38:20 2021
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE833A0A19 for ; Wed, 26 May 2021 09:38:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level: 
X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ye7XVp8aSVBz for ; Wed, 26 May 2021 09:38:13 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130052.outbound.protection.outlook.com [40.107.13.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE4653A0A13 for ; Wed, 26 May 2021 09:38:13 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dIOtY4fQa0HTfHWr4RDzHDGp03b/OGdEZdwGN32okYGar+eNo3bCxMnxq7jfj8S8nEDseH/CvA16JxRtK4Vm6Af97N/a+cjzD+Yb/jyPhPPdnDe9gC1SNnsFkanI6HYAKU7yjMaI3uJyyDB1khIx2zDbsMjpaZpymQI/njP9G8et89Vys9jGzitN3M8kWRC/VfyM7m9eZL946at/ugQ5qV6BmH8XFHI8bb+q3/JUmoxsES7vIyftdz0c6vTAlXtRHHIBpfIqpKJ11X+VZUtLQwB93dbEWO67K6btRIuPpvQcgxXo+CVjYDKHyIkfJs6DVK2Ax25Qo80GZdmCVcsRdg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wQRo3ge6+4AbOgmLpE1jHyywvGrkZ9yVVxeM+GZggXI=; b=IzDFHMm9Gx9HMRccfg1A/HSJAw4Q3QsDPtzKXEcmmRFKVGgiQpG+XZXjgDNqPFG0kuangQXe2rYfzJAW+7JdKZK9Ae+kD5kfeAUsyLix+lY/uOKda5MCw34YbxBlb2j8HcggkZEzP4QrKTf0yqURa/GfZS2GAa6I9llJAZHCmCkoGOI0IPyx7quI7oeZ/7KNSp1f8oyrmYe19vbw6vPqdVyXivq01u625jZNTwrNyaS+n/+OemLnARgqd42ZfDGOBokw2/cMNYmoaMDmCSJcGoBWs0yuqzocP1lPLOjQ8SD0Nn+y8mDz9FHq+RIvzpoyfmq7dpE/l9f09n4ImTFZOg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wQRo3ge6+4AbOgmLpE1jHyywvGrkZ9yVVxeM+GZggXI=; b=m6rlv1zAp4VBo8IH3F8lYoKdOz4fYNsL1ceeRnRrPLJuo98CTwPUwDOG6Qxwe6jNqj1qohjsuwOhFZ/vN/e6YsdD9HcvDIxmD/HgYmMTbJYHJZICvoPTN5aw62Lp0FlUlM5gWGU6YJQ/c2GYHGaBFXcPN7ex82tzG2/+51XrKRY=
Received: from AM0PR07MB3860.eurprd07.prod.outlook.com (2603:10a6:208:4c::18) by AM4PR07MB3313.eurprd07.prod.outlook.com (2603:10a6:205:e::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.15; Wed, 26 May 2021 16:38:10 +0000
Received: from AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::b10f:ebc0:80d:db2]) by AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::b10f:ebc0:80d:db2%7]) with mapi id 15.20.4173.021; Wed, 26 May 2021 16:38:10 +0000
From: Christer Holmberg 
To: Thomas Richter , "avt@ietf.org" 
Thread-Topic: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
Thread-Index: AddLKBOH9HzaEV4jTtmQ8TPYzmKsqwFVwo+gABfRKwAAFpWSgABEymJQ
Date: Wed, 26 May 2021 16:38:10 +0000
Message-ID: 
References:    <7aa5e890-47c5-cdb7-5657-26864cec3d4c@iis.fraunhofer.de>
In-Reply-To: <7aa5e890-47c5-cdb7-5657-26864cec3d4c@iis.fraunhofer.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: iis.fraunhofer.de; dkim=none (message not signed) header.d=none;iis.fraunhofer.de; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [80.248.247.159]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5063eb4b-46ee-49ac-898f-08d92064a64b
x-ms-traffictypediagnostic: AM4PR07MB3313:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: VFJyrW+QrwypAqWFFPgVE9dNWhm6ZZKOSV0L45Q1voQZjyoDiSt3VVlAELEIFTN99hhoxAVLle/TN315ld0rWlAKJwXQ9toHo62eRt82xsNfcx4d9tSt+EgpHCCnVCUDcbv5STBiiiMVR0FYU9HDVKO6sWGVxm4HLdI4u9fRarXXIUiL4h4CK6oJaQnXX8DwZHa+YP9vBfe17Ih6C3SpEGVod+3tGADPHlVQfDGydal5tRsOXzsl5Z8Zm6ER57VUubBY9NWne0KPeKbVxdw08PJA5EMLwjgMVXQMKHpStW7ByqR+WPobmJ2osrpDvVDePxipEStn7F1KzMZc3hLKSM3QAV90AgSXZx+dFht1K1Xjf/l+/h6cQZg/vyNcxBiA0kcbvST89qDu0YtkBphCWjhbsf/dBw23RHL/RnB+6D1q1T1YiEOZ+Nkhh6P0idrF/elY1rhSTPoMGy/1J7gjBwvDy4mhsDUoHYJBwKIKyY7mpK4mRO6NCRawWCD0Zxl0MxyEjr0zK5Z+WITw3kEwwvTJModRmU+glOuQTWFW4ts/iS3lZcHNefBjWbwMtkhC/oRi1jrUblSmkdA/8ykaVETh+GJ/iLYcns6nSjA1FpU=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:AM0PR07MB3860.eurprd07.prod.outlook.com; PTR:; CAT:NONE;  SFS:(4636009)(136003)(346002)(396003)(39860400002)(376002)(366004)(38100700002)(110136005)(316002)(5660300002)(33656002)(186003)(76116006)(478600001)(122000001)(8676002)(55016002)(66446008)(44832011)(66476007)(64756008)(66946007)(66556008)(9686003)(52536014)(26005)(7696005)(86362001)(6506007)(2906002)(71200400001)(8936002); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?bJRZMCbsz8kuBH/Vx7/jyRgC2DYJDC2hMObTBxmqE2UI2cukENLSLOXdUvRu?= =?us-ascii?Q?06oMbhf3zkpzbq/K0DqOSuKaSma1NKD8DZ0fPjW0L/yVf6a1uTiMeJJJ0AoF?= =?us-ascii?Q?xlv4F15QzEKYS3naKUKL9yJ39TFYZwTqTy45AboB2LAu/cI5f10AOyykU36I?= =?us-ascii?Q?6GHTOizyvy1sZ1TnaKwjaR2oSarhSnr/nIX8H4HKtCuz1EtZb3sCK/CnxQPx?= =?us-ascii?Q?KOio1EzlurVVGeT7RKsEJ/TIpfo3myFLnPoe7+XX0/qozmkSRm6dShkmAnSq?= =?us-ascii?Q?yyxn3QRDolDmm6jAvsm89txew9Vz0552lJHKYapWf78ehMaM9vfizlAKoyQG?= =?us-ascii?Q?qSQmBsbxSSiJH/XA+IqJyTaDepXw6wuYBUQJCK9CTMiBN0WBcYfZCmqDji84?= =?us-ascii?Q?Lpp16H5k2kUiZ3Nmh4a6SwEydMU1YZcLSEfc3xUd0ahZdLruptd1BGSoKeC+?= =?us-ascii?Q?rPff4loHMWy9BuaexhVwDa0yot3FAJW9WB3jtpHGDuLtAnD9HYBxPU8o264u?= =?us-ascii?Q?jhSBSLXQDdqvlshpQekooVBmOfQzTvcEks0WSqDqE7pYVl5nfbPHeLXmd4Ek?= =?us-ascii?Q?B/icdLPKJkIEM/7Ks5UA03R+OspDl15IpuW+Jdxh55MEdtgjjxnuD+Ln930E?= =?us-ascii?Q?9AblFP0gcgkvG1CNFnrisBhZq4AkDJSQsRQaUlF4HgNG+hotQV5RI9BaKECM?= =?us-ascii?Q?UeCevxDrB9MPXVAM4h2hnNMYMOBTBPHj23Bb23Av4ZCzlCIy0nB8JJ03Lto7?= =?us-ascii?Q?ZnTazMVh5uB2cii0jOasGHm+eMxgvqRm195mA+o5i5eZrcmCbU5bUFoh9vCB?= =?us-ascii?Q?jJ45OCes6duk4D6dbbMY74VCZSrOy/hXKf+OwnM80fFkyhRBK65kkxXx+JYk?= =?us-ascii?Q?ewbmbGp5f+KylCthacsysi1PIsaExystJN+qsmlZcjOUqhmcBikEoxMUR7rt?= =?us-ascii?Q?8YYl3snaNNrLlz6E8K3mrJqg+qyBA7Ze9aaXoCpzZU2Qa1Q5vgEbZLeAEMg2?= =?us-ascii?Q?BDLCp9B1acW/0EXOhUjtKbIyRp9HDw2QWzUKEjb5aD2tf2LMURjQZmTSTALH?= =?us-ascii?Q?GL0pU+Y0k+xTrQEQNgX2gs0N2vlwecs6DJycRF5bY5lyOou/LY5eBGNJ5yyM?= =?us-ascii?Q?Gl5hXrSSoGDOGrcQTDcbe1zVDxIBVnH2Y/qJcFiexKF/8jFw4n28ifJ6cpCI?= =?us-ascii?Q?wc9hu5oCv6AGMt4U7KVHkh/DWf5YLaTuUblk20R8ebdhl6HYDbJLbKs7tPUm?= =?us-ascii?Q?UMgH56cyYgKPRzAz2NLRq74ILPo0LHB3V+7RZ9sg+0nO8Nd8Vr9s83WQOVyV?= =?us-ascii?Q?6pWxdqwbOYM6KD/p6efYsxV+?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB3860.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5063eb4b-46ee-49ac-898f-08d92064a64b
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2021 16:38:10.7443 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 2rZvcnUWo8fEf8k346gpNgk3tFsFcSkDB0QCdmLVxr5XlevtsX+6YHU0mpqLEWR6Y6iZxVb2d3qWpjreyw4b573uP24cCHJffbuCXDIMZH4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3313
Archived-At: 
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 May 2021 16:38:18 -0000

Hi,

>> Unfortunately I don't think what you explain above is very clear in=20
>> the text.
>>=20
>> Consider the following.
>>=20
>> The offerer sends an offer. The offerer specifies the characteristics=20
>> that the offerer wants to receive. Similarly, the answer specifies the=20
>> characteristics that the answerer wants to receive - the answerer does=20
>> NOT specify what it is going to send. which I think the text is=20
>> currently describing.
>
> Sorry to sound confused, but maybe you could explain a bit better. To my =
understanding, it is the offerer that describes what it offers to send, and=
 not the other way around?=20
> Maybe I misunderstand something very fundamental? Sorry to ask these elem=
entary questions, but this is important for the text.

In SDP Offer/Answer, the default is to indicate what you are willing to REC=
EIVE :)

Typically your receiving capabilities also implicitly indicate what you are=
 able to send. For example, if I am indicating that I am willing to receive=
 codec X it normally means that I am also able to send codec X.

 But, there are cases where that is not true, especially when it comes to v=
ideo codes where you typically have more parameters associated with the cod=
ec, and one needs to explicitly indicate sending capabilities.=20

---

>> "The receiver SHALL ignore any unrecognized parameter or invalid=20
>> parameter value."
>>=20
>> First, In my opinion invalid parameters values shall trigger an error.
>>=20
>> Second, what is an unrecognized parameter?
>
> I wonder why we need to specify this, i.e. what a receive does about para=
meters it does not recognize? Essentially, this is a problem of "foreward c=
ompatibility". Wouldn't it
> be a matter of implementation whether the receiver accepts an offer (note=
 well, the receiver), and attempts to decode a stream on a "best effort" ba=
sis, keeping in mind that
> the stream itself includes additional means to identify required capabili=
ties necessary for a successful decode.
>
> If that is not an option, we would/could need means to identify the type =
of parameters in a foreward compatible way. I.e., conventions by which we w=
ould identify in the future
> parameters a receiver can safely ignore and attempt to decode, and parame=
ters a receiver cannot safely ignore.

I think it is fine to say that unrecognized parameters shall be ignored. It=
 is then up to future specifications to worry about backward compatibility,=
 rather than this specification worrying about forward compatibility.

>> Also, the text does not say what restrictions (if any) there are when=20
>> it comes to modify the stream during a session. Is it allowed to=20
>> modify any/all characteristics?
>
> My understanding is that you cannot modify characteristics during a sessi=
on. If you need to modify, you need to setup a new session and cancel the c=
urrent one. For JPEG XS stream decoders,
> one cannot expect that an instanciated decoder can decode from modified p=
arameters in mid-stream level. That is, if you start decoding in full-HD, a=
nd then stream parameters become 8K, the
> decoder will have to abort.

These kind of things need to be specified. I don't think it needs to be for=
bidden to try to modify something, because there could be text that strongl=
y recommends against doing it.

Regards,

Christer


From nobody Wed May 26 09:42:47 2021
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C36B3A0A5E for ; Wed, 26 May 2021 09:42:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level: 
X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Faz0fKCfVQT9 for ; Wed, 26 May 2021 09:42:40 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80058.outbound.protection.outlook.com [40.107.8.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8483E3A0A4C for ; Wed, 26 May 2021 09:42:40 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W6wMCWjJ1piuI7d5Tfo2NIbrTjL5kgag2V7vNrp2/BxDSfCWHRlecYkqN8bm3vOjP2LLU+4wxqCChgimx48rA4McyXViqbwLO0w9DK9/PCVsG5xBjc3o5jthkIzZNry0Zl1P4sEZ+0JGgbWt5iIO5c84yRLMEkXh9lYkza3nXVfB9qq9eqYQ9SS1wBrafRKZof/kqucfBFor6+O8e5kxIqVUKZHmPK1TQn+nFJrKBD2VHQzyZgH/0rMyR4qJzMU0kW4o5AoBnfsUi02Ak4fZZMZP4SvIpcfpB/vmS708HDbRoRUnR7VINHLGM8hgEa76hAaA56Eso0dyFsXe/Nkr3A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zDCRoF/Hkus/LDx+50kgA6mq45H6BEatZjt0xjTnyr4=; b=goUI8sM1Yz5IBWXtuat9IxdvyBHsWRyIhJIXgy3vVZBXUxhx7+KrxzPFukkPUp0ofhfqeB+soL+YVa/u5ZDw6ynjDI2pwR6zCVW2A5f54wdQoktNK/1KzqpwF02sJMAu1k6+V1YQYA8JSTLviGt0CpMSh5E1dx/CYj2VUatHAFBbNjknqqfchw3Kb62nXeUhfU2Y0lYW2Sp6gkde/cYGpXEAHcrOK6fsxqaMbd2UEA0z4Yohum3UzLtSI6mZd2vuX/fdNgeoTb5ZG0qkWv8ywWdOKkU2N7PHupWByRhZGICBpBvvknASZrakbeYXZ5kl6gtkT0j4HT7HmbUvoWLrWw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zDCRoF/Hkus/LDx+50kgA6mq45H6BEatZjt0xjTnyr4=; b=CVn3TdoeMsuCQwKZPP0rqqgL21dL8Hf621l0cKFbiBU4c0/lf5BW5CIRrVPVdmOf3POHYO0zZe/XUby6ns6dBV4aeFv0Ay3/4bvw4LHtC4QhaMJMnoCpOZua8WgYIssFiFXuoexfnkP8axfU8ZD1ekjYRUULIxeg2zKCTpAihe0=
Received: from AM0PR07MB3860.eurprd07.prod.outlook.com (2603:10a6:208:4c::18) by AM4PR07MB3313.eurprd07.prod.outlook.com (2603:10a6:205:e::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.15; Wed, 26 May 2021 16:42:37 +0000
Received: from AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::b10f:ebc0:80d:db2]) by AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::b10f:ebc0:80d:db2%7]) with mapi id 15.20.4173.021; Wed, 26 May 2021 16:42:37 +0000
From: Christer Holmberg 
To: Thomas Richter , "avt@ietf.org" 
Thread-Topic: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
Thread-Index: AddLKBOH9HzaEV4jTtmQ8TPYzmKsqwFVwo+gABfRKwAAFpWSgABEymJQAABwR+A=
Date: Wed, 26 May 2021 16:42:37 +0000
Message-ID: 
References:    <7aa5e890-47c5-cdb7-5657-26864cec3d4c@iis.fraunhofer.de> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: iis.fraunhofer.de; dkim=none (message not signed) header.d=none;iis.fraunhofer.de; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [80.248.247.159]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b34e9c72-3928-4051-d770-08d920654575
x-ms-traffictypediagnostic: AM4PR07MB3313:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 1Euk2l6AqdlBXxzhUg/Udz9Mt3DacJCy/XA1bi6uobGpe98QKEsuV0ZLx7y93KdsauYWkPWbgv1QnyUOAz8oo5F18iIolIixF8t8SFwNwyvZpk71WZGNsvQKDDFqPVm8oi2PcQRKo+XdkBxxMkEiJGKWez01lIZLg0VdVTsvKGtFEZ0ZHS5omLAHokdf9YdIBB7wy3oj9cit2Ut++u9AsazOi2U3AvPIbFR5xgP6i8MmFBwr39sWLvaH0zHKM4+DpRitZgkHgHZ67sXlNJr+VnhelYrJ+BN7B4zi0A3w95t2ySrcWLgsV1BL1XZhbLIBpC2mmaiJ/zRAxtfNwy9Xd/jR4qFPz4D9NGR8taWoSGKX7diKxrqJTb8dY5Kru2ISXAd0x0tyFmRpN41Z1zPX1dvTqslYA/kgtlNjOeAU/VQS+V+Gur6FuremcEUpN3aVKyt4FY+ByqC40uSv2a9sJH+K4jtMJh/+4xe0c0gHbJiaRuiBGyLf7rAsRmBwBqoCc9BjzGYBC7jx+XXtujY9l8rQdDzBYXQtXcdLI9BV6llxnSOIXJTMV2wqAOyBvgOo1AbzYL9hefFfLdQW78hITRaiTkNLsUU4HxogPAZMjbhMVFyjY5redz15i+QgJPNFvCDwbNLO3ilMx5YDtI8tZ6i7CVJodeJiwtTjV7vDBM0tPTsh42n+aVuTPXWxF3861jdu0TAegW8YL4MnwbiflPqBFNs//kEJyU2XCvoSDFc=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:AM0PR07MB3860.eurprd07.prod.outlook.com; PTR:; CAT:NONE;  SFS:(4636009)(136003)(346002)(396003)(39860400002)(376002)(366004)(38100700002)(110136005)(966005)(316002)(5660300002)(83380400001)(33656002)(186003)(76116006)(478600001)(122000001)(8676002)(55016002)(66446008)(44832011)(66476007)(64756008)(66946007)(66556008)(9686003)(52536014)(26005)(2940100002)(7696005)(86362001)(6506007)(2906002)(71200400001)(8936002); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?DbSOP8CJj+tuPyl2Fzh9XXeS3hRmLQk7IHNfaeQGLVrsGUDFcqiK1UyqArSK?= =?us-ascii?Q?SUoavwC4b9OucyKn4n25K/wh/IJmQgV4vRe9pROg9TsGhV3/ZHNtFmnlNPPm?= =?us-ascii?Q?uMJ57dWtXmHlQ57R7zuuUtTSNMtkojopHPlg7ghwON8QZGy75bRxOl6TSZMQ?= =?us-ascii?Q?BuL2FQvgsBHhgx9PUvy8f+y8E3LBmA2ykIAGPYq/pQDrW3eQoTYO1AW3l3NS?= =?us-ascii?Q?I92dJvNvzMC6oxkWTlIKRuoMtCEG5jHJZA9kya2D/evjXatsg90q2b76lj3S?= =?us-ascii?Q?GrE6CMzj5DlPJOg25dx82qrae1Dsur02LGrcNqjzipNosZcEefeoIRPbSnU2?= =?us-ascii?Q?n41p6+ndSzu5Gl22Fi/ocWuM1r9c7tJabxQZuPG8L/OKfnamShbMnbOzgp/i?= =?us-ascii?Q?Jo+tdWS0VDbk+kc5vKHWKhc2gp4/xQzsYg3lXlfLxDKNYvX26rvCSawDOlNW?= =?us-ascii?Q?6h9fZNv7p487iysx7Vlm4rMuHgfdpBCxurakK2wJetvdNh2V/F09DwljoUNf?= =?us-ascii?Q?yRr3/6/odyCYgK2aGeAWcKqzANPs11LCI1ZFmZVIjNLPgnhymUWsahi17ZK7?= =?us-ascii?Q?ZolyzsPhrwaFYGK4wBLSupPZFEzctlBuQu5uNncyGVtjmyJgMTt7SaKW+HS7?= =?us-ascii?Q?iZesG5+kvNIDTu6wASTFfOSxB8SwMj/Xwz7BUzembjOO3qCXZjrASbhyvZtS?= =?us-ascii?Q?3IIlEX3c6vCP9fO2BWO51tGVNesP5g+bW/fQAi5ygQZdyIrTLB0Wnh1uVgPS?= =?us-ascii?Q?wFi88ps8kJhNgTkNaHpqfEBiUdUARTtPovLJEiF5Ur1x1li634CaDhINA8dN?= =?us-ascii?Q?9fWl0zIGdzuDu7XaU2EmIPi1Zo6btc0ru1A05vuzk7u9zQyaBTI16brD7928?= =?us-ascii?Q?uuYBGBSW10B5tN4PeH4EPx1hc6pKKv5vUTPSsn2RX2uCsqbjyhwMUuPPmaGD?= =?us-ascii?Q?qgO0/Te+bxrmsRvVYDNhaWJdjYvpk8C+jb5tz6cJ8m7etek5bWg48eyJsSk2?= =?us-ascii?Q?6dJDiZ+v8vj/qIpWRcil1xM7M3QVj5P5sYw/jDV5sbd6hE5R6u5Hb0WuT+aN?= =?us-ascii?Q?TjYvvN5gKuFDT6D7gkctU/dUmCGt7FbftGfHGXBNPz+3ygL8D2hfbGptBuwy?= =?us-ascii?Q?DVn4dD2NpPm4H0iiEWt7JrvjUsL6e4cB1F6AEdIYzt6z2Q2d5SFgGlpr3HQg?= =?us-ascii?Q?JnpI76TX8k2f43LZycCt44CsYQC4sa9KkfobMbvSDDmuT4bmUbSca60T7m4y?= =?us-ascii?Q?pwVo3Ucri7aB94ADVuADfzlhvprPv92Sa8f2LwdZ8+1mtOFXWe+0/RNilpVg?= =?us-ascii?Q?6so0uYa2VkocqEG6vkKsCiZ2?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB3860.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b34e9c72-3928-4051-d770-08d920654575
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2021 16:42:37.7423 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ACt1mKzo5N+hsgINd9VayQvrY/vzgzLbxpgbd43hCRIZzd5lQ/hDvsrv51X+4lqe3ulhaaf8lBHrodKV6Cyixxm3UQSLznwWYW85YK0VTGY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3313
Archived-At: 
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 May 2021 16:42:46 -0000

This is a structure that is typically used for SDP offer/answer procedures:

X.  SDP Offer/Answer Procedures
     X.1.  Generic SDP Considerations
	
     X.2.  Generating the Initial SDP Offer
	
     X.3.  Generating the SDP Answer
	
     X.4.  Offerer Processing of the SDP Answer
     7.5.  Modifying the Session
	

Regards,

Christer

-----Original Message-----
From: avt  On Behalf Of Christer Holmberg
Sent: keskiviikko 26. toukokuuta 2021 19.38
To: Thomas Richter ; avt@ietf.org
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpe=
gxs-13

Hi,

>> Unfortunately I don't think what you explain above is very clear in=20
>> the text.
>>=20
>> Consider the following.
>>=20
>> The offerer sends an offer. The offerer specifies the characteristics=20
>> that the offerer wants to receive. Similarly, the answer specifies=20
>> the characteristics that the answerer wants to receive - the answerer=20
>> does NOT specify what it is going to send. which I think the text is=20
>> currently describing.
>
> Sorry to sound confused, but maybe you could explain a bit better. To my =
understanding, it is the offerer that describes what it offers to send, and=
 not the other way around?=20
> Maybe I misunderstand something very fundamental? Sorry to ask these elem=
entary questions, but this is important for the text.

In SDP Offer/Answer, the default is to indicate what you are willing to REC=
EIVE :)

Typically your receiving capabilities also implicitly indicate what you are=
 able to send. For example, if I am indicating that I am willing to receive=
 codec X it normally means that I am also able to send codec X.

 But, there are cases where that is not true, especially when it comes to v=
ideo codes where you typically have more parameters associated with the cod=
ec, and one needs to explicitly indicate sending capabilities.=20

---

>> "The receiver SHALL ignore any unrecognized parameter or invalid=20
>> parameter value."
>>=20
>> First, In my opinion invalid parameters values shall trigger an error.
>>=20
>> Second, what is an unrecognized parameter?
>
> I wonder why we need to specify this, i.e. what a receive does about=20
> parameters it does not recognize? Essentially, this is a problem of=20
> "foreward compatibility". Wouldn't it be a matter of implementation wheth=
er the receiver accepts an offer (note well, the receiver), and attempts to=
 decode a stream on a "best effort" basis, keeping in mind that the stream =
itself includes additional means to identify required capabilities necessar=
y for a successful decode.
>
> If that is not an option, we would/could need means to identify the=20
> type of parameters in a foreward compatible way. I.e., conventions by whi=
ch we would identify in the future parameters a receiver can safely ignore =
and attempt to decode, and parameters a receiver cannot safely ignore.

I think it is fine to say that unrecognized parameters shall be ignored. It=
 is then up to future specifications to worry about backward compatibility,=
 rather than this specification worrying about forward compatibility.

>> Also, the text does not say what restrictions (if any) there are when=20
>> it comes to modify the stream during a session. Is it allowed to=20
>> modify any/all characteristics?
>
> My understanding is that you cannot modify characteristics during a=20
> session. If you need to modify, you need to setup a new session and=20
> cancel the current one. For JPEG XS stream decoders, one cannot expect th=
at an instanciated decoder can decode from modified parameters in mid-strea=
m level. That is, if you start decoding in full-HD, and then stream paramet=
ers become 8K, the decoder will have to abort.

These kind of things need to be specified. I don't think it needs to be for=
bidden to try to modify something, because there could be text that strongl=
y recommends against doing it.

Regards,

Christer

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt


From nobody Wed May 26 13:35:53 2021
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42DA3A160A for ; Wed, 26 May 2021 13:35:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steweorg.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BMVsCPB1_pi for ; Wed, 26 May 2021 13:35:47 -0700 (PDT)
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2136.outbound.protection.outlook.com [40.107.236.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AB393A1606 for ; Wed, 26 May 2021 13:35:46 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eS5TVhz3D975J0yc5NQt4kEw+HbXgCYxipn61Npvf8IiOIVzk97LOAAyTqhrOwt9slWgoaRYDmP+XXbqshC99ayRjVPu1+JP4jK6gU9M0QhAPR+fze1TkIi3EWkrjdawTXKqYOU59bc5xpsds8sjqkgnRFXTjRHBR4Sa3JLrxXgpyCI5BibTbuF1sGB5xc0bYKQjsjVS/JYl72+YBhcPvE78QOHliUaNKPlLhtFxENzqCrgC3ybuSLwd2eJ+zVwpkmKx0fFdLIZEyjCzF0rCoSqE7G1yhk/RbXoPCZJCza52bkl7AF9qKBOd3sgyyr29wlAzkkzYffmmcwzyosmZkg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nzD+0rW7w/guTZIh7lLOnJHUWa1bU8aEfsyWoPHJMJk=; b=bHNSvzGTHRBEdZSTomRIaHaSHjZtxIpkDz5jmlGaZBYzufjMejKu0N6SFnIYFnwUKxxKXS9WGU32L+EAVuGHh/YWzaAWf0SC2rPjQFkuxCk9ZEwxbDWyvE4mlV9tzOw0kc00F0Auwg64DcmGQXp15Ex/udMqnl/9uXji1oI6W9t1bXVM4fm279g1ktUDIFX89gra3uQWI73wK2miAfYaCfiUMKGaJHniRvkTtP+sJ0Isw/bZPU4x+V3PSm6Zf3uI9URIrDQJw0H8RmAT0pUHYUZ4uSa7Akp1I7Ma4oNMixGLf9FxnhT4qsCUyw3d8S8C6ce64+QdFylHBwGpDJg63g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=stewe.org; dmarc=pass action=none header.from=stewe.org; dkim=pass header.d=stewe.org; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=steweorg.onmicrosoft.com; s=selector2-steweorg-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nzD+0rW7w/guTZIh7lLOnJHUWa1bU8aEfsyWoPHJMJk=; b=A5//zHGYnhzIKMTxOLTK3uA5VELWdQ7AVlKf5v4BCNN8BMcVB1l+yY4g59RqtSkSHkJcbcoebmdvywB1xAPRsFB4wcjHATi8vhajaynPI22E2YobxYINXu42gN6mupdXeTa0SJ4IOs0f0+EmFpJzTxBlMdU/bvhb+AisVVmQgUY=
Received: from PH0PR17MB4784.namprd17.prod.outlook.com (2603:10b6:510:8c::17) by PH0PR17MB4734.namprd17.prod.outlook.com (2603:10b6:510:87::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.27; Wed, 26 May 2021 20:35:42 +0000
Received: from PH0PR17MB4784.namprd17.prod.outlook.com ([fe80::5c1d:8b25:806d:fc9c]) by PH0PR17MB4784.namprd17.prod.outlook.com ([fe80::5c1d:8b25:806d:fc9c%4]) with mapi id 15.20.4150.027; Wed, 26 May 2021 20:35:42 +0000
From: Stephan Wenger 
To: "avt@ietf.org" 
Thread-Topic: VVC payload format, open issue cluster #3 (editor-notes #24, #11, #19, and #20)
Thread-Index: AQHXUm6yNcyd4tVOU0Cex59ZdFHkrg==
Date: Wed, 26 May 2021 20:35:41 +0000
Message-ID: <66DA47EE-7953-41E1-804A-614E53C6ACCA@stewe.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/16.49.21050901
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=stewe.org;
x-originating-ip: [2601:640:8300:1f:590a:b9bf:b3bb:8387]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0210327f-7c7d-4127-487b-08d92085d4d1
x-ms-traffictypediagnostic: PH0PR17MB4734:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ddej7woVmqKKa44M0rm2a7lh9vsh9+SuoUfsajwzyLs58ejjECqU10kglLtMmeE6JeaQwAHZLg8x+81uo4A5mk5xcQthopl+z5K4pss5dTA10lgh1U1+1vs3+qmB0NGLpR6GbLOfb7P+6NyWvmT7zfqt69kkobEBKqzJKeh9wkMG1Wjx5SmzS1CZLx433YDFGH0FKxnW0Pi3+d9Qe7FAYy2EVuqGW/fgp8MfjhV+2xCF37tqqccOlEhU30ND1JFb+L4wmsqrSM3bEtXW96zSQCbCHq8gKmwsPn2VjHCKU2ln+UZ9VgU+xdcPiw1GZ6D0sdiCa0w85Y4g8ONHS5KdFz5ibWVUefQRRS4AO27ECPx8vKEfKnB4E8bVZCK4gv+bOlcF9wSZGTwAJdSmc83ZdQlI8s5SuWfLPZ5lBX2YP+n3fuLK4P5eSen179fnvE+ByGSPxoukSel3KO4cZ2xMKgrnl1jrMz7ajxNTfQH6cauAl5uGkUBJ1NoxQEUCYgU0lTtlz2UpPrm4vgKNS1GwZonkkmPk+q1k+5LDB0RgS5m64SZdqyOrYohaxhVf3Uj7/CdaOhvRWR2mLCIsskwf636hIlaY9AeFQ/i9PhYQAdBvireXFUftjrANDaWrc7mFsVg9waoQvDdDgrZFcaHZvwojB+Yl63k5fnsmlLx6X+wOTmzExSk/UXYKxc3jbM6bNnXW6D/SgzRlo3EU7cdXWRvddygy9XuUKeCEAiJnf/1uLE8nameCP+abooRLkCuAe7kM1bB3Gf3ZpkMRO9Hejg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:PH0PR17MB4784.namprd17.prod.outlook.com; PTR:; CAT:NONE;  SFS:(376002)(346002)(136003)(366004)(396003)(39830400003)(2616005)(38100700002)(166002)(122000001)(36756003)(33656002)(2906002)(71200400001)(6512007)(64756008)(6506007)(83380400001)(66946007)(66476007)(76116006)(5660300002)(478600001)(66446008)(86362001)(6916009)(66556008)(6486002)(186003)(8676002)(8936002)(316002)(45980500001); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: =?utf-8?B?aWhSbC9hMEF3OUdCUEFRemNqY2JzTDZtNHljRzUzTCtrOGsvOWdQVFE0UmVn?= =?utf-8?B?NUs2SFVkUzNFUXZDQmtFVjdiN1BhQ0RvU3c0N0h2V1A0SXAvMTIwYVNid3Bi?= =?utf-8?B?WE1pMnVGbnFMbkNaa0c2ditTUUp6OVdtS2NDaUYwdUhRUStzeXZFM0FuSVZ2?= =?utf-8?B?UFFIclB0K3VydGVGUm9NTTQ5eWdDOHpNZHd3aFpvRnppRUYrOXFid3FWZCtQ?= =?utf-8?B?dllvenJNdUlzZ1JCUzlzVE1PMGxhaGhoSUNCWXJtQUtMcngwcUl5OWhxWTk0?= =?utf-8?B?NHlRakJyYWhKaXRaMW9uaWFYYVJFVFRGOGIwRTNDNWJ5ZDRDcEc5TFZ6azZu?= =?utf-8?B?SWVYc3B1bldreTFPTkFzTzMxaUtxVlp4cUVScC9UcVc5cEs5R09LbXg1aU9Q?= =?utf-8?B?MFZFOVYxOXFKMFk5VURCZFZJU0NZaENucWJQcmR4QTRNTGVobFkwc21xUEs4?= =?utf-8?B?OEJBY2dLUXFJVGR0RFlzTG9CZ204bENmSVFJV3V6VDhSNWlvbGp2T2pUdjRD?= =?utf-8?B?SGhhckM2UnE0c0hGUUllSW93djFPbEhhMmRmcmNtZ0ZNL3dFSU01b1czSGVh?= =?utf-8?B?S1A2eGVTWklQOFVaQUdIU2NvZy9UN25JRFp6VThRcCtLdnBPckloQUpZVFRK?= =?utf-8?B?QS9XOW5TNUlFMGtiaG8vWHdYNlVCRDBZVzVKTk9CSHp0Y2wwM1R0STJndWRU?= =?utf-8?B?SGJxemUyZkhjWHJwUXBKdm1rZGpwQm5KZXpHaVlpRDllVFFwc0poODlYcXZG?= =?utf-8?B?eGRrWkJnOWMvNGp1dVRiWXV5OUIrRjBkTDBTNEdGOW05VjNWRjhNdFZ0TVJJ?= =?utf-8?B?dXBKKzdrTjMwU1hoTEpUVEVUOVhwZkRIYU53cmZadXNKenM2THJSMGNxQ0lD?= =?utf-8?B?eElBNm1wQU5WMWlvc1QwSVo0N2I4VmVvelVmTHk4bmY1d09XUDl2dnpuTUVV?= =?utf-8?B?UW0yb3dBK1o2Y2NMRDlmK3dCT0l4SjNsZEJ3cVFZRHlEcnZzRThjSWxXZ0sv?= =?utf-8?B?U3RHbHludVJOMnIrNWNla2VaLy9ieE9EUldCczVOMW1KTzREYUhqV0pLbFph?= =?utf-8?B?Mkk0UVF5ckl2V2FGU25JTWY1a0hTK25xVjk0bllySUZnSXNJZ2NDMHNOa0lS?= =?utf-8?B?cFVyNEdOcHMrYVROdTNZY1l4N2JZcHBFaXcwaGV6WVNHZlgxb1UwOVFMYS9w?= =?utf-8?B?VVl4aXNSVnRBT0x4WWk2MDBpYkFmV3JZODRnTVh3UWhyUk9NWHZhVTduOXZM?= =?utf-8?B?aTRMdkxIUDlOZFRmbnNCZkd4dHhXbzMrR2thWkR3Zit6QWZzVGVCNDdPQWF5?= =?utf-8?B?T2JvZUZmMUZVREs1VHIzV1FjbGFOL2ZwOVQ0T2hWSzRFekRtM3R4TmU4cW5D?= =?utf-8?B?em9icm0vb01EZElFbGhXRHJsRVpXbjlleVlKSVR2OUZDNC9VSEtqYmw3d0xH?= =?utf-8?B?eXdFVVN3WHdOTWNmMm9MOHlzL1daQ0ZqWUNjcHZYSUxhbWNoVXBWQVRVNFph?= =?utf-8?B?YWhaSUlCZG9nQzNtOGZ6TjA5bzE5ektTaDR4Ymhqc2lGYlBZR0lScks4U3pk?= =?utf-8?B?RGwwV0pmaVhVanlXV1NVNlFucCtoQmhWMm95NC9UN1NWazgrUk43UGtuSGpO?= =?utf-8?B?U01oY2psTWVnMDVsK1MzazFlenhrUy90MXd5WlR0S3craGl5Zm5TZ2F5R1Bu?= =?utf-8?B?SmUyT1VETjBRWGZVck5GY0pnTFBQNCsxMjNEb1IvYStqbjc5bE5ydnNzcE1R?= =?utf-8?B?NnlvYVRnMTVMOVFaQmtRaENVSWgxSVAxazhnb0M4TlFwamxxWTRkREYvMy9k?= =?utf-8?B?ZUxsY2VTcm1RNFBsYXJBOWxuRGkyOXljeGNNYmRld2tCTExZa0FqWFQ4NTBO?= =?utf-8?Q?8i0D2bIpm0BuJ?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_66DA47EE795341E1804A614E53C6ACCAsteweorg_"
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR17MB4784.namprd17.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0210327f-7c7d-4127-487b-08d92085d4d1
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2021 20:35:42.1815 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: tTOD4kzFWZD9YpNV75qfWCmbTptb0/G5qGCp+fzaER1IA/HGCZMptHD34sh3SZiu
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR17MB4734
Archived-At: 
Subject: [AVTCORE] VVC payload format, open issue cluster #3 (editor-notes #24, #11, #19, and #20)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 May 2021 20:35:52 -0000

--_000_66DA47EE795341E1804A614E53C6ACCAsteweorg_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QWxsOg0KV2UgaGF2ZSBhIGZldyBlZGl0b3LigJlzIG5vdGVzIG9wZW4gaW4gdGhlIGN1cnJlbnQg
dnZjIGRyYWZ0IChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWF2
dGNvcmUtcnRwLXZ2Yy8pLCBhbmQgaGVyZSBpcyBob3cgd2Ugc3VnZ2VzdCB0byBkZWFsIHdpdGgg
c29tZSBvZiB0aGVtLiAgUGxlYXNlIGNvbW1lbnQgd2l0aGluIGEgd2VlayBvciBzby4gIEFic2Vu
dCBjb21tZW50cy9kaXNjdXNzaW9ucywgd2Ugd2lsbCByZXYgdGhlIGRyYWZ0IGluY29ycG9yYXRp
bmcgdGhlIGNoYW5nZXMuICBUaGVzZSBzaG91bGQgYmUgcmVsYXRpdmVseSBlYXN54oCmDQoNCkVk
aXRvci1ub3RlIDI0OiAgV2UgcmVjZW50bHkgaGFkIGNvbnNlbnN1cyBvbiB0aGlzIGNoYW5nZS4g
IFRoZXJlZm9yZSwgd2UgcGxhbiB0byByZW5hbWUgdGhlIGJpdCAo4oCcUmVzZXJ2ZWTigJ0gd291
bGQgYmUgYSBiaXQgbWlzbGVhZGluZyA6LSkgYW5kIHJlbW92ZSB0aGUgbm90ZS4NCg0KRWRpdG9y
LW5vdGUgMTE6IHRoZSBzdWItcHJvZmlsZSBJRCwgaW4gVlZDLCBpcyBhIDMyIGJpdCB1bnNpZ25l
ZCBiaW5hcnkuICAgVGhlIGN1cnJlbnQgdGV4dCBzdWdnZXN0cyB0aGF0IGJpbmFyeSB0byBiZSBy
ZXByZXNlbnRlZCBieSBhIGJhc2UgMTYgUkZDNDY0OCByZXByZXNlbnRhdGlvbi4gIFNpbWlsYXIg
ZmllbGRzIChiaW5hcmllcyBpbiBWVkMsIHN1Y2ggYXMgc3Byb3AtdnBzLCBzcHJvcC1zZWkgZXRj
LikgdXNlIGJhc2U2NC4gIFRoZXJlZm9yZSwgd2Ugc3VnZ2VzdCB1c2luZyBiYXNlMTY0IGhlcmUg
YWxzbyAoaXQgc2F2ZXMgYSBieXRlIG9yIHNvKSBhbmQgdG8gcmVtb3ZlIHRoZSBlZGl0b3LigJlz
IG5vdGUuDQoNCkVkaXRvci1ub3RlIDE5OiBJIGJlbGlldmUgd2UgaGFkIGFuIGFncmVlbWVudCAo
YXQgbGVhc3QgaW4gc3Bpcml0KSB0aGF0IHBhY2tldGl6YXRpb24gbGV2ZWwgYnVmZmVyIG1hbmFn
ZW1lbnQgaXMgdW5uZWNlc3NhcnkuICBCYXNlZCBvbiB0aGlzIGRlY2lzaW9uLCB3ZSBzaG91bGQg
cmVtb3ZlIHRoaXMgbm90ZSwgYW5kIGFsc28g4oCcY29uZGl0aW9uIELigJ0gaW4gdGhlIHRlbnRo
IHBhcmFncmFwaCBvZiBzZWN0aW9uIDYuDQpIb3dldmVyLCBwbGVhc2Ugbm90ZSB0aGF0IHRoZSBi
dWZmZXIgbWFuYWdlbWVudCBoZXJlIGlzIG5vdCByZWxhdGVkIHRvIG1lbW9yeSB1c2FnZeKAlHdo
aWNoIEkgdGhpbmsgd2Ugc2FpZCBpcyBhIG5vbi1pc3N1ZSBub3dhZGF5cy4gIEluc3RlYWQsIGl0
4oCZcyByZWxhdGVkIHRvIG1pbmltaXppbmcgc3RhcnR1cCBkZWxheSwgYW5kIHRoYXTigJlzIGRl
ZmluaXRlbHkgbm90IGEgbm9uLWlzc3VlLiAgVGhlbiBhZ2FpbiwgdGhlIG1lY2hhbmlzbSBkZXNj
cmliZWQgaGVyZSBoYXMgYmVlbiBwcmVzZW50IGluIHRoZSBIRVZDIHBheWxvYWQgZm9ybWF0IGZv
ciBtYW55IHllYXJzLCBhbmQgSSBoYXZlIG5vdCBzZWVuIGEgc2luZ2xlIHN5c3RlbSB0aGF0IHVz
ZXMgaXQuICBJdCBjb3VsZCBhbHNvIGJlIHRyaXZpYWxseSBib2x0ZWQgb24gbGF0ZXIsIGluIGNh
c2Ugd2UgZmlndXJlIG91dCB0aGF0IHJlbW92aW5nIHRoZSBtZWNoYW5pc20gd2FzIGEgbWlzdGFr
ZS4gIFRoZXJlZm9yZSwgd2Ugc3VnZ2VzdCB0byByZW1vdmUgaXQgZnJvbSB0aGlzIGRyYWZ0Lg0K
DQpFZGl0b3Itbm90ZSAyMDogd2Ugd2lsbCB1cGRhdGUgdGhlIGV4YW1wbGUgZm9yIHRoZSBuZXh0
IHJldmlzaW9uIGFuZCByZW1vdmUgdGhhdCBub3RlLg0KDQpXaXRoIHRoZXNlIGVkaXRvciBub3Rl
cyB0YWtlbiBjYXJlIG9mLCB3ZSBoYXZlIG9ubHkgdHdvIGxlZnQ6ICMxNCBhbmQgIzIxDQoNCg==

--_000_66DA47EE795341E1804A614E53C6ACCAsteweorg_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6
ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz
cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjND
MTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh
bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5
bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9
DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu
IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv
bjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2
M0MxIiB2bGluaz0iIzk1NEY3MiIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYg
Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbGw6PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBoYXZlIGEgZmV3IGVkaXRvcuKAmXMgbm90
ZXMgb3BlbiBpbiB0aGUgY3VycmVudCB2dmMgZHJhZnQgKDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy
YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYXZ0Y29yZS1ydHAtdnZjLyI+aHR0cHM6Ly9k
YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1hdnRjb3JlLXJ0cC12dmMvPC9hPiks
IGFuZCBoZXJlIGlzIGhvdyB3ZSBzdWdnZXN0IHRvIGRlYWwgd2l0aA0KIHNvbWUgb2YgdGhlbS4m
bmJzcDsgUGxlYXNlIGNvbW1lbnQgd2l0aGluIGEgd2VlayBvciBzby4mbmJzcDsgQWJzZW50IGNv
bW1lbnRzL2Rpc2N1c3Npb25zLCB3ZSB3aWxsIHJldiB0aGUgZHJhZnQgaW5jb3Jwb3JhdGluZyB0
aGUgY2hhbmdlcy4mbmJzcDsgVGhlc2Ugc2hvdWxkIGJlIHJlbGF0aXZlbHkgZWFzeeKApjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5FZGl0b3Itbm90ZSAyNDombmJzcDsgV2UgcmVjZW50bHkgaGFk
IGNvbnNlbnN1cyBvbiB0aGlzIGNoYW5nZS4mbmJzcDsgVGhlcmVmb3JlLCB3ZSBwbGFuIHRvIHJl
bmFtZSB0aGUgYml0ICjigJxSZXNlcnZlZOKAnSB3b3VsZCBiZSBhIGJpdCBtaXNsZWFkaW5nIDot
KSBhbmQgcmVtb3ZlIHRoZSBub3RlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FZGl0b3Itbm90
ZSAxMTogdGhlIHN1Yi1wcm9maWxlIElELCBpbiBWVkMsIGlzIGEgMzIgYml0IHVuc2lnbmVkIGJp
bmFyeS4mbmJzcDsgJm5ic3A7VGhlIGN1cnJlbnQgdGV4dCBzdWdnZXN0cyB0aGF0IGJpbmFyeSB0
byBiZSByZXByZXNlbnRlZCBieSBhIGJhc2UgMTYgUkZDNDY0OCByZXByZXNlbnRhdGlvbi4mbmJz
cDsgU2ltaWxhciBmaWVsZHMgKGJpbmFyaWVzIGluIFZWQywgc3VjaCBhcyBzcHJvcC12cHMsIHNw
cm9wLXNlaSBldGMuKQ0KIHVzZSBiYXNlNjQuJm5ic3A7IFRoZXJlZm9yZSwgd2Ugc3VnZ2VzdCB1
c2luZyBiYXNlMTY0IGhlcmUgYWxzbyAoaXQgc2F2ZXMgYSBieXRlIG9yIHNvKSBhbmQgdG8gcmVt
b3ZlIHRoZSBlZGl0b3LigJlzIG5vdGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVkaXRvci1u
b3RlIDE5OiBJIGJlbGlldmUgd2UgaGFkIGFuIGFncmVlbWVudCAoYXQgbGVhc3QgaW4gc3Bpcml0
KSB0aGF0IHBhY2tldGl6YXRpb24gbGV2ZWwgYnVmZmVyIG1hbmFnZW1lbnQgaXMgdW5uZWNlc3Nh
cnkuJm5ic3A7IEJhc2VkIG9uIHRoaXMgZGVjaXNpb24sIHdlIHNob3VsZCByZW1vdmUgdGhpcyBu
b3RlLCBhbmQgYWxzbyDigJxjb25kaXRpb24gQuKAnSBpbiB0aGUgdGVudGggcGFyYWdyYXBoIG9m
IHNlY3Rpb24NCiA2LiZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkhvd2V2ZXIsIHBsZWFzZSBub3RlIHRoYXQgdGhlIGJ1ZmZlciBtYW5hZ2Vt
ZW50IGhlcmUgaXMgbm90IHJlbGF0ZWQgdG8gbWVtb3J5IHVzYWdl4oCUd2hpY2ggSSB0aGluayB3
ZSBzYWlkIGlzIGEgbm9uLWlzc3VlIG5vd2FkYXlzLiZuYnNwOyBJbnN0ZWFkLCBpdOKAmXMgcmVs
YXRlZCB0byBtaW5pbWl6aW5nIHN0YXJ0dXAgZGVsYXksIGFuZCB0aGF04oCZcyBkZWZpbml0ZWx5
IG5vdCBhIG5vbi1pc3N1ZS4mbmJzcDsgVGhlbiBhZ2FpbiwgdGhlDQogbWVjaGFuaXNtIGRlc2Ny
aWJlZCBoZXJlIGhhcyBiZWVuIHByZXNlbnQgaW4gdGhlIEhFVkMgcGF5bG9hZCBmb3JtYXQgZm9y
IG1hbnkgeWVhcnMsIGFuZCBJIGhhdmUgbm90IHNlZW4gYSBzaW5nbGUgc3lzdGVtIHRoYXQgdXNl
cyBpdC4mbmJzcDsgSXQgY291bGQgYWxzbyBiZSB0cml2aWFsbHkgYm9sdGVkIG9uIGxhdGVyLCBp
biBjYXNlIHdlIGZpZ3VyZSBvdXQgdGhhdCByZW1vdmluZyB0aGUgbWVjaGFuaXNtIHdhcyBhIG1p
c3Rha2UuJm5ic3A7IFRoZXJlZm9yZSwNCiB3ZSBzdWdnZXN0IHRvIHJlbW92ZSBpdCBmcm9tIHRo
aXMgZHJhZnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVkaXRvci1ub3RlIDIwOiB3ZSB3aWxs
IHVwZGF0ZSB0aGUgZXhhbXBsZSBmb3IgdGhlIG5leHQgcmV2aXNpb24gYW5kIHJlbW92ZSB0aGF0
IG5vdGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldpdGggdGhlc2UgZWRpdG9yIG5vdGVzIHRh
a2VuIGNhcmUgb2YsIHdlIGhhdmUgb25seSB0d28gbGVmdDogIzE0IGFuZCAjMjE8bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_66DA47EE795341E1804A614E53C6ACCAsteweorg_--


From nobody Thu May 27 23:49:43 2021
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F17103A1D22 for ; Thu, 27 May 2021 23:49:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.886
X-Spam-Level: 
X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=intopix.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuwA7Kw5YhJe for ; Thu, 27 May 2021 23:49:35 -0700 (PDT)
Received: from dispatchb-eu1.ppe-hosted.com (dispatchb-eu1.ppe-hosted.com [185.183.29.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4306D3A1D1F for ; Thu, 27 May 2021 23:49:35 -0700 (PDT)
X-Virus-Scanned: Proofpoint Essentials engine
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04lp2051.outbound.protection.outlook.com [104.47.12.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1-eu1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 0B6DA6C007B; Fri, 28 May 2021 06:49:25 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RB38ya56UgmqawN0z80vGBuuCVF/e6fTLrfVKKeCUP70hcu0gbLIYwyKXNLGC1kQ+4vmKeQldDgQtT11jjQa55f0o65sPMRtAXB3LK5bcj9AUtDT6l+UzF/oXbgYBd4FlSP45vPJepXRgygqdNIh2fdlIIhIpSf4trJW2t4rKr2uQsrIhFdkGsdLvll4Mg/x4cEWb225t/d71W2qTxn8ceHvDyVWw/Rw0rmPSA+0WqwG84pMzqbzoP+zfgVjpiTSNJXQYx/En37GN55tBO2SgNM6JCKnFnhQ61wCueV/J8oNf7ccQPlsn4EE/o2fCzVXKT5gxusGOqUWHEvE0vEvCQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Hksk58tATe5TS5SnhNb4czJhcF6RSONrPfV1wN4tRhA=; b=Izaa8JNTPfM5R/qjEKrU9mV3UPmb3cUEwkwn4Kj1KgSdfwK8GkYN84pglnHU7L+XeKaMGC5dw1z2c2IQCs2JA8wZjHBzw7S0yAb3dDnsIbVzGYg1yuEQciax5HjWzNvBzMgUx+XrgCGO8XyXiWQoqstXLDp7V6e6eG636FT5MQ7Wz83/9cAIJjx/Y09BMvo3W3164KwH9KlnB+98YCVB5sd+qkANQiOpHtXYAK0CrCjcLjx0v0pQc4snAyq5JGXog5TniiYeNeIhq5AtKBhhf79CaZjihtqdfgQB/6rJ5rtCIw68c2IHvKllWQkODqguUlUsOLT8Y3MLkBcpOBYadw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intopix.com; dmarc=pass action=none header.from=intopix.com; dkim=pass header.d=intopix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intopix.onmicrosoft.com; s=selector1-intopix-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Hksk58tATe5TS5SnhNb4czJhcF6RSONrPfV1wN4tRhA=; b=gqT6xh/ezeg/1Bc2dZzEhmXzHJ4C27NDF8QdENt45veRPHkaBwy+rwyQgoc9bBT69/8kWGCS21fSb6q/mRMHVLlCrqhbAibfQ9uIY9l1Bdz/vKM8yXBEfgPi36eJTYcJnjgWzhoR7CFNciiJb9Jf/j/kGXqT3JOSVtLfyZ2VfyM=
Received: from PR3P192MB0748.EURP192.PROD.OUTLOOK.COM (2603:10a6:102:4f::24) by PR3P192MB0556.EURP192.PROD.OUTLOOK.COM (2603:10a6:102:47::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.27; Fri, 28 May 2021 06:49:24 +0000
Received: from PR3P192MB0748.EURP192.PROD.OUTLOOK.COM ([fe80::8ab:c06a:c2cf:b0ac]) by PR3P192MB0748.EURP192.PROD.OUTLOOK.COM ([fe80::8ab:c06a:c2cf:b0ac%9]) with mapi id 15.20.4173.020; Fri, 28 May 2021 06:49:24 +0000
From: Tim Bruylants 
To: Christer Holmberg , Thomas Richter , "avt@ietf.org" 
CC: Jean-Baptiste Lorent 
Thread-Topic: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
Thread-Index: AddLKBOH9HzaEV4jTtmQ8TPYzmKsqwFVwo+gABfRKwAAFpWSgABEymJQAABwR+AAT0NxwA==
Date: Fri, 28 May 2021 06:49:24 +0000
Message-ID: 
References:    <7aa5e890-47c5-cdb7-5657-26864cec3d4c@iis.fraunhofer.de>  
In-Reply-To: 
Accept-Language: en-US, nl-NL
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=intopix.com; 
x-originating-ip: [94.227.86.241]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6aa7c120-a51c-489f-db3a-08d921a4bb0a
x-ms-traffictypediagnostic: PR3P192MB0556:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:4714;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ybDLvPHNY11+pmGHqKVJQvedRRnewjuODCsORuxHqOhxWbgsvaChL/U4MoTBWdEg/QldU/IZsx6AHZC1k+pTiC3te6AGnv1T1SsRWFlj73UlWg3KP9IO1cfYCVhL+e1xGjxeadwwXedD6cX4QHpWYllduBnE52GPtPMg3RKkawwJh0yHWCN6BqAN1QfEmRV2vZ5dD1CQ0AvMinCvXpj/L0NnRzCxLT8VthAGSuaao0czS31H63473pWiMx7Xg/lVEf8saGIj5I0YDT2KDNURCq4yKxD2VQyBDu6zMso1dc63aqyzcMiQUbx2SAjVnff66OhB6BUGbMpykiCo7iLSHxoOXQsT2WAOsh8+9XEuFtDrTiySfiAuGRRaVdy/kB+3T/wgIundvmB47VACdI+MEQUEw24Btj/d3yl4JDR7ZSv0kSeoetMYkhElmxDPZzXgiy3AozRmDP1ZxYyE1LzEnJOA+QmdOoy7+71TJxPDlpCUU4FPdzocuMCxl4fezhiwcecuiPy84wxV04Ip2sPrHbaKGTokFO+svoOjnlYfM6zgEBRZKWcrMdAkFbTHRwFO/soajLlzCrCBVIdCvS6OOQlp3Nuhps7VDTdW/lfLU5vpbBCvUkmpWR5MH/FoUNh3VlnoaAyXPk0m4ilwCT9FnLA7L2OGRCj1OUN+KqvajUP9HK6SMlycqCRGHd1ZRXH/bj4YpHsiD/i9GQYYTE7d0qePDGi6gASPRUtCPfE3Nh8=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:PR3P192MB0748.EURP192.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFS:(366004)(39830400003)(376002)(136003)(346002)(396003)(66446008)(64756008)(26005)(66556008)(316002)(76116006)(110136005)(53546011)(2906002)(966005)(6506007)(71200400001)(478600001)(5660300002)(122000001)(55016002)(83380400001)(66476007)(4326008)(66946007)(52536014)(9686003)(8936002)(8676002)(86362001)(7696005)(33656002)(107886003)(186003)(38100700002); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?juNuGdU5wmn8qtAHgx/wqmQErFOengv1/7sJDSsGmmhZDQcyYFN9AJd53lg5?= =?us-ascii?Q?zvucSwQvf531B13iimx/SfNL1DWlldYEodrRK4TA8k/PkDHfscp5Vy4d5IGF?= =?us-ascii?Q?wGyh/HNtccLcFoMi4XaoucePfKhaHAZEPfTcfYvnp4RABS8R66uGpQIkpc+m?= =?us-ascii?Q?RSa9GSbdiw91vRVxmOp1gugBKnS2GPz4Ypjr13Z2/f9hnfiiiWSazbDqveK0?= =?us-ascii?Q?MQh/LqE5jG4MDv9zvzM06rsNCOzo5uJGSMOs2/3c55psq1ghJyXcIR3TQOi8?= =?us-ascii?Q?rHcazeYPOPn5r1Nc+AWVxyWxl7fM00mME+lWMOq13EZAZ6DYPUbmbVw76eyS?= =?us-ascii?Q?ob0fNuFn7/4BEfzCGUPG406qRa5Al/MqP2ThdhXkeZPEfha5aD61lSbDcRZ1?= =?us-ascii?Q?DXtVxhdKTTkd4njwHGYzfuCLa1m5uVvDMOibHmYOXEnn/fSNNmdpPxvmQs/N?= =?us-ascii?Q?tZwmPCjp9dPDIc5M9HRxrG9r+7Ww1QiELhVdTqZW1/kiAg6tIGi9Ae1GntdO?= =?us-ascii?Q?24o0g1PAdfDk9udpAH6/gHVJTArmgT0RQl8Wo7JNXnFfRMCp4GDJWotHdSSM?= =?us-ascii?Q?BXYrfla3JBRRSAqcUXC+D/wNhBj3SLzILp1oRB1UeMYXfm67PU6iJ4rJ+xUS?= =?us-ascii?Q?5QzxDGxNqQ+aTr+LDqiRu3SN3TZ+S6I6uaRgPH05bvPRk1NU0j6FWsXKjhfu?= =?us-ascii?Q?15ryA/XAVt0lCqZajFt78LeJ6WBl0mPVJqTIm9ZZICnv4axrHaOW/ygVY5hl?= =?us-ascii?Q?VQEICb1xxHiuU2LwhOI2QAr7Bth6WCuQZuAqBU6wEB08CDHnAmyCKmoomVUE?= =?us-ascii?Q?VS9KKCVDkLCAkwgf506t1pJaDNoB4WmIRHzZ6FAXAtIj0RbNY0ZZkyI+VzPK?= =?us-ascii?Q?lZ/CRjeEXZK2HJQK6cpF9QdX0REmRGhOorRTRF0nO2rWjyBejAgpF/TqLwk+?= =?us-ascii?Q?iR7sccpaBJFIbQdFm1ulyL3DhGAZJfQiZz6UbPcVv9ZaZ4TiKG1SY17Z5tVQ?= =?us-ascii?Q?/qWTFM3oPEHzT2iSTAlW61goFhyngahzW+Ef2zAS/y/z3G/cGJ6z4YOaxs6T?= =?us-ascii?Q?gibFbwRIAsFsARQnIT3bOfWBbtNp8kzc1vwruXO4gRpPQvTa13ZxS7M52PDJ?= =?us-ascii?Q?3cHXoYQSsbx+P4zrGSRbWWoqQXIPCiw/tjTXqh7TPinSUDIMP3/qXxWJpUP5?= =?us-ascii?Q?vUFZzIcjOMsrdmJbAom2htVzy0HOiM2TfB/dStdeTqAHuL5jik0NT4icIDoq?= =?us-ascii?Q?AnfnWFczBf82xnxYPijR8W1ldueVhaPzZXGGVOJ/N5j7/A+zQMWghJZm6lRV?= =?us-ascii?Q?Mk1BF8NmPdnlZWGrnvro6MAB?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: intopix.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PR3P192MB0748.EURP192.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 6aa7c120-a51c-489f-db3a-08d921a4bb0a
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2021 06:49:24.4257 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5f9168c7-cdac-4b23-9509-c278399e3c1f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: tbZU9DCXajUdosqM/ES7ckcZ/p5TdlSut1nnLNqJoFqroEtP5yfHsFRXNBf6s9wd
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3P192MB0556
X-MDID: 1622184567-ZbYL95E7ODGZ
Archived-At: 
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 May 2021 06:49:41 -0000

Hi Christer,

I'm a little bit stuck in how to resolve and address your comments. On one =
hand I understand that we want the text to be clear, but on the other hand =
we do not want to repeat SDP specifics too much. SDP is just one way to neg=
otiate a session, and in the case of XS it is not the most commonly used on=
e. XS is not really intended for the classical video-call case, but rather =
to stream high-quality video content in a professional environment. It can =
be used for video conferencing, but better suited codecs exist for that use=
-case.

However, what is important to lay out correctly is the mapping of the media=
 parameters into the a=3Dfmtp field of SDP, because this is actually used b=
y many other protocols (so, just the media description part of SDP is used)=
.

Originally, we based our draft text on RFC 8450 (VC-2 HQ RTP Payload). In t=
hat respect, what is written there kind of fits exactly what we want with X=
S. Given that this is a published RFC, we are puzzeled a bit as to why our =
draft would need to elaborate so extensively on SDP. For sure, we'd like to=
 allow SDP offer/answer negotiation with XS. But this is very simple: each =
side tells the other side what it supports, and that's it. In XS the parame=
ters are declarative, meaning (at least that's what we want to express) tha=
t each parameter is represents an exact value and is not "inclusive" into a=
 range of lesser values. In other words, the other side cannot expect that =
a "lesser" value of a parameter can work.

Your proposed structure is just to elaborate and out of scope. As such, I w=
ould ask you to consider the example of RFC 8450 (where the use-case and pu=
rpose matches that of our draft). For example: Why do we need to state anyt=
hing specific on "Modifying the Session"? Isn't this layed out by SDP on ho=
w to modify a session? There's nothing specific to be put in our draft (we =
do not want to prevent, not suggest this functionality).

I hope you can understand our difficulty with your remarks and comments. Ou=
r proposal as such is to keep the text about SDP very short and simple. The=
 RTP Payload draft can be used with SDP, but it's certainly not the only wa=
y.

I will be preparing an updated draft which tries to be very minimal on the =
SDP specifics. Unless anything is technically wrong, I really hope you can =
agree to it and move forward with the publication process.

Best regards,
Tim.


-----Original Message-----
From: avt  On Behalf Of Christer Holmberg
Sent: Wednesday 26 May 2021 18:43
To: Thomas Richter ; avt@ietf.org
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpe=
gxs-13

This is a structure that is typically used for SDP offer/answer procedures:

X.  SDP Offer/Answer Procedures
     X.1.  Generic SDP Considerations
	
     X.2.  Generating the Initial SDP Offer
	
     X.3.  Generating the SDP Answer
	
     X.4.  Offerer Processing of the SDP Answer
     7.5.  Modifying the Session
	

Regards,

Christer

-----Original Message-----
From: avt  On Behalf Of Christer Holmberg
Sent: keskiviikko 26. toukokuuta 2021 19.38
To: Thomas Richter ; av=
t@ietf.org
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpe=
gxs-13

Hi,

>> Unfortunately I don't think what you explain above is very clear in=20
>> the text.
>>=20
>> Consider the following.
>>=20
>> The offerer sends an offer. The offerer specifies the characteristics=20
>> that the offerer wants to receive. Similarly, the answer specifies=20
>> the characteristics that the answerer wants to receive - the answerer=20
>> does NOT specify what it is going to send. which I think the text is=20
>> currently describing.
>
> Sorry to sound confused, but maybe you could explain a bit better. To my =
understanding, it is the offerer that describes what it offers to send, and=
 not the other way around?=20
> Maybe I misunderstand something very fundamental? Sorry to ask these elem=
entary questions, but this is important for the text.

In SDP Offer/Answer, the default is to indicate what you are willing to REC=
EIVE :)

Typically your receiving capabilities also implicitly indicate what you are=
 able to send. For example, if I am indicating that I am willing to receive=
 codec X it normally means that I am also able to send codec X.

 But, there are cases where that is not true, especially when it comes to v=
ideo codes where you typically have more parameters associated with the cod=
ec, and one needs to explicitly indicate sending capabilities.=20

---

>> "The receiver SHALL ignore any unrecognized parameter or invalid=20
>> parameter value."
>>=20
>> First, In my opinion invalid parameters values shall trigger an error.
>>=20
>> Second, what is an unrecognized parameter?
>
> I wonder why we need to specify this, i.e. what a receive does about=20
> parameters it does not recognize? Essentially, this is a problem of=20
> "foreward compatibility". Wouldn't it be a matter of implementation wheth=
er the receiver accepts an offer (note well, the receiver), and attempts to=
 decode a stream on a "best effort" basis, keeping in mind that the stream =
itself includes additional means to identify required capabilities necessar=
y for a successful decode.
>
> If that is not an option, we would/could need means to identify the=20
> type of parameters in a foreward compatible way. I.e., conventions by whi=
ch we would identify in the future parameters a receiver can safely ignore =
and attempt to decode, and parameters a receiver cannot safely ignore.

I think it is fine to say that unrecognized parameters shall be ignored. It=
 is then up to future specifications to worry about backward compatibility,=
 rather than this specification worrying about forward compatibility.

>> Also, the text does not say what restrictions (if any) there are when=20
>> it comes to modify the stream during a session. Is it allowed to=20
>> modify any/all characteristics?
>
> My understanding is that you cannot modify characteristics during a=20
> session. If you need to modify, you need to setup a new session and=20
> cancel the current one. For JPEG XS stream decoders, one cannot expect th=
at an instanciated decoder can decode from modified parameters in mid-strea=
m level. That is, if you start decoding in full-HD, and then stream paramet=
ers become 8K, the decoder will have to abort.

These kind of things need to be specified. I don't think it needs to be for=
bidden to try to modify something, because there could be text that strongl=
y recommends against doing it.

Regards,

Christer

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman=
_listinfo_avt&d=3DDwICAg&c=3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=
=3DLTxUGukLCEfEUdo_bq048Q&m=3DLtefQiLhdrXwUycah7Zmsayk_dtHF-hMEBwHo6Dpet0&s=
=3D1vZTuFjI-QbexP5oX9pga35dZZzthXGgn7S8Zgod9LE&e=3D

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman=
_listinfo_avt&d=3DDwICAg&c=3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=
=3DLTxUGukLCEfEUdo_bq048Q&m=3DLtefQiLhdrXwUycah7Zmsayk_dtHF-hMEBwHo6Dpet0&s=
=3D1vZTuFjI-QbexP5oX9pga35dZZzthXGgn7S8Zgod9LE&e=3D


From nobody Fri May 28 01:39:14 2021
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E113A2083 for ; Fri, 28 May 2021 01:39:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level: 
X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWt8vQCRI36k for ; Fri, 28 May 2021 01:39:07 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60055.outbound.protection.outlook.com [40.107.6.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6216A3A2082 for ; Fri, 28 May 2021 01:39:07 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iOgbFuW/f2vbxM5BHCPPzaX7zb4innkTgIVR8LLyXwkWQF0/+zZWBIqALEkhGaFWlNmjqCbLdugqnYvsl3UURUp3mm6dJTLqNvVw2kw4fpfRzofNoEpZIUz5ioLqSYXYZkXLfl8kdPfU3aXbvDpZIWZLwOQ+ppj/4vsIlY5O+XJiUsGfg2t/aoUVOfJsMuJJOS7pawnUeXyvCR/6BdOGopsOqg4iBIDCPeNCdE6uqjUCY5kHtb6pNwxJXNsaSkRrRk9QNNlR4++rjDZV/WhsQS9rRWaUm6rXXZrsqO2TravI4wUiVE2IVANaRzwtA833K5vk3E9SZTyHlpxPdSZ+RQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5Q7pNYyhW1SoJI05MKPfErKx9bmxhVrNtuLTZ4pNYiw=; b=FdyNi52UQWtMJWyi2M9WdpAbK+WIQYT1VwhTbiSYKcYE/Q58cxOkZVnirDKFwCq8qZGqgQv/mYTeKi5vsh/1PhtJv5IrlPmZY7Q2T6OfXcTOCJWY4EyqhJshNikafnc5hBu33CP2YNqzQbyak25602TWm9bELYGBnMfjps3Q5ujB40FbaO/YzLLkOc5jNgeLMUCYqrqkCzOSLGZV15gOjA7IrFlPQCpNTceko78KrzekVcds4XyBSfxysinDf1v4uMpEIJRqdFTtlZ9pccHRpPb267zb8VD8k9UL8ggn3FzFzGEUtbiFEX/Ala0yWEGX41mhLtr3cFAZSUs53sR0hg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5Q7pNYyhW1SoJI05MKPfErKx9bmxhVrNtuLTZ4pNYiw=; b=obHazHhSKeA8+jvv43RH/09er+mjsbwGLH3qVUnhXtXvvQpW1YRYvmWPfdRSDGMpEFyno3+aTAq/L+m5VaIT4L6GJLqNI7Er5+o4awd6/lJhecwvx2h6DpWrozgFPK9jOXN6013wIGTOCxIuM6Xg8tO9NDE+v4JAWNuc8LGGjNs=
Received: from AM0PR07MB3860.eurprd07.prod.outlook.com (2603:10a6:208:4c::18) by AM4PR0701MB2195.eurprd07.prod.outlook.com (2603:10a6:200:45::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.12; Fri, 28 May 2021 08:39:03 +0000
Received: from AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::b10f:ebc0:80d:db2]) by AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::b10f:ebc0:80d:db2%7]) with mapi id 15.20.4173.021; Fri, 28 May 2021 08:39:03 +0000
From: Christer Holmberg 
To: Tim Bruylants , Thomas Richter , "avt@ietf.org" 
CC: Jean-Baptiste Lorent 
Thread-Topic: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
Thread-Index: AddLKBOH9HzaEV4jTtmQ8TPYzmKsqwFVwo+gABfRKwAAFpWSgABEymJQAABwR+AAT0NxwAAES3xQ
Date: Fri, 28 May 2021 08:39:03 +0000
Message-ID: 
References:    <7aa5e890-47c5-cdb7-5657-26864cec3d4c@iis.fraunhofer.de>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: intopix.com; dkim=none (message not signed) header.d=none;intopix.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [80.248.247.159]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: cbb2235a-8298-49b7-737c-08d921b40c8e
x-ms-traffictypediagnostic: AM4PR0701MB2195:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:5236;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 61N9i54ehBd+hIthgY/mc+Jo/maveKX2LYRBXOoxyxw52SiaGjzBTmgm6KIEqivdL5FUXPZKZntc8QnJQhpB6WgqXxD5SM7ujREl6CW0OQ2Fzfu6oxGAniOnXHp8x4fDf46B03nzeWcvvdVrspvblgSz92pYOfg15aM6wNQyhx8JkcYgki3HOCydsFpeItvW31nBwuJU9tNc3G9IeFk2iH/hToK8CODfdZxeeWFRWq8kGUhOpYW7mAbOl1Uu0TnQDQiVrbPW9EcZpoLPGk25xeUXZ/i1sltgYYcpg8A8emlYH2/oAFYIPZf1f0pvnINWxKotlFreJBWsIq20hHXN9+sMTakA4bo+hRzSHG9dgkO2+g1k2tLJpj3v8/5Yxuve3DiKY4PWXp7Kp0v2E6hafkyJMko4J3OTKgvjh4TohT+CL7rPxk3FahJePGPyw41dIvi3dbk6kKShFx6SyfCPasSbjSZBTr3wHKOrf7Dhwdnv4rguisftL7faLyolyrOFs26nW7G/xi6K0gOyxmmWstcSRtMXWZa+8jEEA21YMXVVndqV2TOuqn/+iv/r7PSL7Br9Wt9JE4EoLR8Hltk7AUnREWME1Tl8OplufOyNZKsoH8fn+BykkB5UPra6ku5dBFARLndEcss3fqF+n6G6Wm/Mm0MqtDDVneuRwHG/R+uGem18GI3tsvg2yDA5uVzprB9xQFifTwD1pJmQshles7/EI8EgIrHmnnrAO4Mivk4=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:AM0PR07MB3860.eurprd07.prod.outlook.com; PTR:; CAT:NONE;  SFS:(4636009)(136003)(396003)(376002)(346002)(39860400002)(366004)(110136005)(316002)(86362001)(26005)(4326008)(53546011)(52536014)(966005)(122000001)(2906002)(38100700002)(83380400001)(6506007)(9686003)(186003)(64756008)(66556008)(66946007)(478600001)(7696005)(66446008)(66476007)(76116006)(55016002)(33656002)(44832011)(8676002)(71200400001)(5660300002)(8936002); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?rKp/aykETbJlRhSpiW+Mp49tnNFVb+81OFEDNusUqOl1FqfJMRK6CO6UuwBk?= =?us-ascii?Q?uTYlK/fpHcI5RJ/DBjYBm65e7HvJg0IqYXOCMrJynIZVRqiE6j2sCIvbIxR1?= =?us-ascii?Q?5qblr0xvfki5kiT7jWEG+dvQtDfWgPGjN2qnxdrdnW2A+qbFWqTAe3Fo65up?= =?us-ascii?Q?pl/xDecga13x8Boz2E2ACKaQ2b0dlED8RHgw/NLgYPBGmrw2Z5Tq3hXCQMe0?= =?us-ascii?Q?HB74YrYKeMpW7HeubdxE4eQPslDZZmRS4juXbPQSrbnDxieKb4FDkyeoEY7L?= =?us-ascii?Q?3C1tcnPm0kGPh2VCplGvH7CpwqViC1PDW3SU1keuvw/iZhhM2er2zhhood6a?= =?us-ascii?Q?H6oaLtiK9+cGnps7/ukTlUWHJoQ8kpku90P+H3zxM0trSnP2bhQV7iEmvWwG?= =?us-ascii?Q?w26hqOrhsl4bGXt+zTyhH0e3T/J81ImvRCKvZnTOKFdMmgTO3UEgTxIWVTY7?= =?us-ascii?Q?TB3Hv5EdSWBImum6dgflnfs7gp1oUjM0GRsyyn2pTSL0Me7tLLM4W3S60mGW?= =?us-ascii?Q?TxJvIpHDh01RZ7DC+KTHJV0jVgnQHtTiUBRPqY2KMpSbtDFeoQjFewVMueMv?= =?us-ascii?Q?KJcG8up73R1MqPNSRrYf/mXhGFF5SlAJiZwEVuq6Bx9S4M3tw435gJNbBdjL?= =?us-ascii?Q?EcAtTCmaSkXnhn/0ai6pCPhHp1C5Pu+BDruLKV4u35nLIN+uuGes/ggeKdgg?= =?us-ascii?Q?ncxwSnQROP8E2y6hn+7I7DT3ACTuK+yLP9HJzG41cT3773epEcfPJgindaSC?= =?us-ascii?Q?OGRGV47GXHpbaj/d6mukzRsBUdRfGeovxkz8cy9xV7wzbwulac98qE4tt7Su?= =?us-ascii?Q?Qr35Gg6zvqwE8PNQHn1SjsjZN8pBWPPsh4AdysS8nX87KHbRZ905pucQ4CYX?= =?us-ascii?Q?B0Mn8FGmFuOVuzzP+djh/lRZhT0VAuxir4EeZrRimzkxR1Y0hwqj3JhK9y9L?= =?us-ascii?Q?XrATjTopE9qr9TSl6fMJBt8OPyLAFNrLgy7ZynhyJfZF9Z86+zPNOnRvwW6k?= =?us-ascii?Q?O8iwF0o6BSTnO+ayX1WQR3sHG+yUqu1EIk7slLdLER6UYCJtyTWtxAKGIdWQ?= =?us-ascii?Q?xM4vIP3Im2L+FeS/YrnZmOQXJe066eKql3eab9JBMP7QB6SlaOuQtlFnx3Xa?= =?us-ascii?Q?svArMP3A6lKsxlsK9tCq+cqrE3gjCrxItxF1ZQScjsy91AibqKg/tiYdhQV5?= =?us-ascii?Q?Z0gWPxTjLxSpEBeaeFev/3NGAgzkGe9WW84hybtom5rmYwBlkXSbAOcwPGl1?= =?us-ascii?Q?SuqQnC9PvYn9CyXiKDwlqL1xut/iKs5OuSW9eEOGeUeJTxeLxw7a7rbOq4Rw?= =?us-ascii?Q?qvnBVrynOvs4+emNU7B/h0ui?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB3860.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cbb2235a-8298-49b7-737c-08d921b40c8e
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2021 08:39:03.6368 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 5mzpmL/9cDU2DbrpwuL2aKP8OdIR19BG6H7Acol9lnrLP8vRYv5yKiPHKamD9cuJZEcQ6mLn0/3Gs7/+PwFd/7c/ni0lwb6qarIo/FraqOY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0701MB2195
Archived-At: 
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 May 2021 08:39:13 -0000

Hi,

First, regarding RFC 8450, that specification was probably never reviewed b=
y the SDP directorate, so I can't really comment on that. But, I see that t=
he RFC e.g., says nothing about whether the SDP indicates sending or receiv=
ing capabilities.

Second, nobody mandates you to use SDP, and most part of the spec is protoc=
ol independent. But, the "SDP Offer/Answer" section describes the SDP offer=
/answer procedures, *IF* you choose to use that mechanism for negotiating t=
he session.

Third, I don't think you need very much text. The important thing is to say=
 what is placed in offers and answers, whether there are constraints when g=
enerating the answer, and whether there are constraints when it comes to mo=
difying the session. And, you do NOT  need to specify HOW to modify a sessi=
on, but whether there are payload-specific constraints when doing.

Regards,

Christer

-----Original Message-----
From: Tim Bruylants =20
Sent: perjantai 28. toukokuuta 2021 9.49
To: Christer Holmberg ; Thomas Richter ; avt@ietf.org
Cc: Jean-Baptiste Lorent 
Subject: RE: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpe=
gxs-13

Hi Christer,

I'm a little bit stuck in how to resolve and address your comments. On one =
hand I understand that we want the text to be clear, but on the other hand =
we do not want to repeat SDP specifics too much. SDP is just one way to neg=
otiate a session, and in the case of XS it is not the most commonly used on=
e. XS is not really intended for the classical video-call case, but rather =
to stream high-quality video content in a professional environment. It can =
be used for video conferencing, but better suited codecs exist for that use=
-case.

However, what is important to lay out correctly is the mapping of the media=
 parameters into the a=3Dfmtp field of SDP, because this is actually used b=
y many other protocols (so, just the media description part of SDP is used)=
.

Originally, we based our draft text on RFC 8450 (VC-2 HQ RTP Payload). In t=
hat respect, what is written there kind of fits exactly what we want with X=
S. Given that this is a published RFC, we are puzzeled a bit as to why our =
draft would need to elaborate so extensively on SDP. For sure, we'd like to=
 allow SDP offer/answer negotiation with XS. But this is very simple: each =
side tells the other side what it supports, and that's it. In XS the parame=
ters are declarative, meaning (at least that's what we want to express) tha=
t each parameter is represents an exact value and is not "inclusive" into a=
 range of lesser values. In other words, the other side cannot expect that =
a "lesser" value of a parameter can work.

Your proposed structure is just to elaborate and out of scope. As such, I w=
ould ask you to consider the example of RFC 8450 (where the use-case and pu=
rpose matches that of our draft). For example: Why do we need to state anyt=
hing specific on "Modifying the Session"? Isn't this layed out by SDP on ho=
w to modify a session? There's nothing specific to be put in our draft (we =
do not want to prevent, not suggest this functionality).

I hope you can understand our difficulty with your remarks and comments. Ou=
r proposal as such is to keep the text about SDP very short and simple. The=
 RTP Payload draft can be used with SDP, but it's certainly not the only wa=
y.

I will be preparing an updated draft which tries to be very minimal on the =
SDP specifics. Unless anything is technically wrong, I really hope you can =
agree to it and move forward with the publication process.

Best regards,
Tim.


-----Original Message-----
From: avt  On Behalf Of Christer Holmberg
Sent: Wednesday 26 May 2021 18:43
To: Thomas Richter ; avt@ietf.org
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpe=
gxs-13

This is a structure that is typically used for SDP offer/answer procedures:

X.  SDP Offer/Answer Procedures
     X.1.  Generic SDP Considerations
	
     X.2.  Generating the Initial SDP Offer
	
     X.3.  Generating the SDP Answer
	
     X.4.  Offerer Processing of the SDP Answer
     7.5.  Modifying the Session
	

Regards,

Christer

-----Original Message-----
From: avt  On Behalf Of Christer Holmberg
Sent: keskiviikko 26. toukokuuta 2021 19.38
To: Thomas Richter ; av=
t@ietf.org
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpe=
gxs-13

Hi,

>> Unfortunately I don't think what you explain above is very clear in=20
>> the text.
>>=20
>> Consider the following.
>>=20
>> The offerer sends an offer. The offerer specifies the characteristics=20
>> that the offerer wants to receive. Similarly, the answer specifies=20
>> the characteristics that the answerer wants to receive - the answerer=20
>> does NOT specify what it is going to send. which I think the text is=20
>> currently describing.
>
> Sorry to sound confused, but maybe you could explain a bit better. To my =
understanding, it is the offerer that describes what it offers to send, and=
 not the other way around?=20
> Maybe I misunderstand something very fundamental? Sorry to ask these elem=
entary questions, but this is important for the text.

In SDP Offer/Answer, the default is to indicate what you are willing to REC=
EIVE :)

Typically your receiving capabilities also implicitly indicate what you are=
 able to send. For example, if I am indicating that I am willing to receive=
 codec X it normally means that I am also able to send codec X.

 But, there are cases where that is not true, especially when it comes to v=
ideo codes where you typically have more parameters associated with the cod=
ec, and one needs to explicitly indicate sending capabilities.=20

---

>> "The receiver SHALL ignore any unrecognized parameter or invalid=20
>> parameter value."
>>=20
>> First, In my opinion invalid parameters values shall trigger an error.
>>=20
>> Second, what is an unrecognized parameter?
>
> I wonder why we need to specify this, i.e. what a receive does about=20
> parameters it does not recognize? Essentially, this is a problem of=20
> "foreward compatibility". Wouldn't it be a matter of implementation wheth=
er the receiver accepts an offer (note well, the receiver), and attempts to=
 decode a stream on a "best effort" basis, keeping in mind that the stream =
itself includes additional means to identify required capabilities necessar=
y for a successful decode.
>
> If that is not an option, we would/could need means to identify the=20
> type of parameters in a foreward compatible way. I.e., conventions by whi=
ch we would identify in the future parameters a receiver can safely ignore =
and attempt to decode, and parameters a receiver cannot safely ignore.

I think it is fine to say that unrecognized parameters shall be ignored. It=
 is then up to future specifications to worry about backward compatibility,=
 rather than this specification worrying about forward compatibility.

>> Also, the text does not say what restrictions (if any) there are when=20
>> it comes to modify the stream during a session. Is it allowed to=20
>> modify any/all characteristics?
>
> My understanding is that you cannot modify characteristics during a=20
> session. If you need to modify, you need to setup a new session and=20
> cancel the current one. For JPEG XS stream decoders, one cannot expect th=
at an instanciated decoder can decode from modified parameters in mid-strea=
m level. That is, if you start decoding in full-HD, and then stream paramet=
ers become 8K, the decoder will have to abort.

These kind of things need to be specified. I don't think it needs to be for=
bidden to try to modify something, because there could be text that strongl=
y recommends against doing it.

Regards,

Christer

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman=
_listinfo_avt&d=3DDwICAg&c=3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=
=3DLTxUGukLCEfEUdo_bq048Q&m=3DLtefQiLhdrXwUycah7Zmsayk_dtHF-hMEBwHo6Dpet0&s=
=3D1vZTuFjI-QbexP5oX9pga35dZZzthXGgn7S8Zgod9LE&e=3D

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman=
_listinfo_avt&d=3DDwICAg&c=3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=
=3DLTxUGukLCEfEUdo_bq048Q&m=3DLtefQiLhdrXwUycah7Zmsayk_dtHF-hMEBwHo6Dpet0&s=
=3D1vZTuFjI-QbexP5oX9pga35dZZzthXGgn7S8Zgod9LE&e=3D


From nobody Fri May 28 03:21:06 2021
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6BB3A2369 for ; Fri, 28 May 2021 03:21:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=intopix.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXcupQfD9jom for ; Fri, 28 May 2021 03:20:59 -0700 (PDT)
Received: from dispatch1-eu1.ppe-hosted.com (dispatch1-eu1.ppe-hosted.com [185.132.181.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41E423A2368 for ; Fri, 28 May 2021 03:20:58 -0700 (PDT)
X-Virus-Scanned: Proofpoint Essentials engine
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03lp2051.outbound.protection.outlook.com [104.47.9.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1-eu1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id CA48C40087;  Fri, 28 May 2021 10:20:54 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aleiukFSm3tejYf6Ne2kEhAf1mYGa/FHnhBDAM5lsPXx1Fj/RwW8xTNrO1SRoy9CeD5ldujYxGyrbRi+k4fvR6EOPheeVpB8466gqcnEHcJgZljxXrCFo5pyHdt4VLSuDLkcwBfAdUU15qD2KQ9nNCKwZrAF1a27tRZSa96CFSuSHswwyXchFjy/o2j4UIKQukbp7eMbKkHpC9Ntjqs7jJ1lLHXlDYSvdA9Z03T9n4xCvxFVUKLGi/5mFiauNICFdDHdRhhuRHrHfZ3NRxAIMWmlysgzraTdnh+wqckYEnYJqUTTRR6nnJ3XWDUIuS18KcblSi1s9yfYKuuIJ59qFA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+KJwLqtwFADgFMLBXsS1g3PuB+yrExHMw40vUCAyW8A=; b=GvMTZJ/DeqmqXvWFV7TlR7IanBFY3kpjQ3shgvWyqojS6Nc0uunUQ5n+j85UrQInA/sHVG10s3WDviScL2hLLe951QktpyY+Cd62pP3vh5bYcnc5+F8k67U1Kmps4Jx4SKaPvuS0GmXQs62K2/g9Q028tIZmw64CA83zrze2sX9FRbxZgClzRwGLoJm7D1L4wcWIk80eaAX8k+tCn7SCHL9rorjeHaO/JcT/blAO/0BiCg5itxq2pEYVIZjpkMd/XNy00jtZ1OWLTBv80sLECUoNsnqp9DtWPkb1Vig1a/rubHJDQ11h9FwDPu1jkFf64SzwNVOAPB1rCwyb6duGQg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intopix.com; dmarc=pass action=none header.from=intopix.com; dkim=pass header.d=intopix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intopix.onmicrosoft.com; s=selector1-intopix-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+KJwLqtwFADgFMLBXsS1g3PuB+yrExHMw40vUCAyW8A=; b=j5Xml5nLhvBobnxwPxQZOe/pJlCDI64rNBw33C/cF6+r+r/esWVxXSADQJKEk65Uoo+OZP/9/N/BC4h5GSL9w6EEMnlSwJnEQ6AX6VzW9JmR/t7yl5sY06xkZJiCNjaoJDrRhoCvB8qnAPV+O9/PZqP63KiCLHlF72pwil8/O3E=
Received: from PR3P192MB0748.EURP192.PROD.OUTLOOK.COM (2603:10a6:102:4f::24) by PAXP192MB1392.EURP192.PROD.OUTLOOK.COM (2603:10a6:102:19b::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.22; Fri, 28 May 2021 10:20:53 +0000
Received: from PR3P192MB0748.EURP192.PROD.OUTLOOK.COM ([fe80::8ab:c06a:c2cf:b0ac]) by PR3P192MB0748.EURP192.PROD.OUTLOOK.COM ([fe80::8ab:c06a:c2cf:b0ac%9]) with mapi id 15.20.4173.020; Fri, 28 May 2021 10:20:52 +0000
From: Tim Bruylants 
To: Christer Holmberg , Thomas Richter , "avt@ietf.org" 
CC: Jean-Baptiste Lorent , Corentin Damman 
Thread-Topic: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
Thread-Index: AddLKBOH9HzaEV4jTtmQ8TPYzmKsqwFVwo+gABfRKwAAFpWSgABEymJQAABwR+AAT0NxwAAES3xQAAEQhVA=
Date: Fri, 28 May 2021 10:20:52 +0000
Message-ID: 
References:    <7aa5e890-47c5-cdb7-5657-26864cec3d4c@iis.fraunhofer.de>    
In-Reply-To: 
Accept-Language: en-US, nl-NL
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=intopix.com;
x-originating-ip: [94.227.86.241]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 81a8d0ce-fe5b-4743-95da-08d921c245df
x-ms-traffictypediagnostic: PAXP192MB1392:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:6430;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 7d890j2zZ4wgLZ2HCfVGLJeqk0MKbEXPv7qJPcvYSTe8743oOPvxSAsmROrmaYQE7oVi/GQMurXgDrRuvQNY+vtIXwBvB8S23SqCqaFEBo10kJXz7mNdPW63LcECbk08FjOO2MebWUgBcHJkKAhNlt9kx3588jIUi6LaLMEI6gfRj8/tuKWfwyXiF9J5igGZ7VM6EOcZEnlj9+ytKG6AaYW7w2ZhXENi9K/Kjj55f4xLiyAwm7m7IEyfl2gS2iLlC9AuF5+7C0vLlSWXfZkQJNBfLq3dnYoiJRrrz6RSX+ohSfo8WYCxSAu3uZahYREikmEOtAA8FiFgJ9stGhcGHPaG0TQzZoaSlo1e5PQ+0xjyQNzAHyr5rR9GYQ+GlnPu066RnuNPns64UkLuWb7+onD5gPGpwJSVRHNGAQ6roKjLir3fQdvDsm8qqASeO/z47M6k/3v7x9hXva5Czj1JKEpzuXhZGz7kVVYuwrhz8It5MYGLh8qanksjuJ9t+RTYuItPhIb1HcnUV0x42J8jwWnvp6mWroYGx5ru6eKKllU+31UvPfRlU22PQR8o4Z48JmCJbsOx4vqhnlwz3kyiWquY89J8cni9kdPclMj/TvF3iOX9eQ/Itpck1rX/yx5hzT0aP6yIh+jNQDn+hoIkIw9vSAzo4SXVB8uyWoSbhXfLUxOXUwHAYGXEE9MwauGnMzhi7AUReE/6Qe221P86uvTu5sJZRh7OR0oYsFAEVSM=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:PR3P192MB0748.EURP192.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFS:(136003)(39830400003)(396003)(346002)(376002)(366004)(66556008)(66446008)(66476007)(64756008)(4326008)(53546011)(66946007)(76116006)(52536014)(2906002)(83380400001)(9686003)(186003)(6506007)(316002)(8936002)(7696005)(966005)(38100700002)(26005)(30864003)(8676002)(54906003)(71200400001)(5660300002)(107886003)(110136005)(55016002)(122000001)(33656002)(478600001)(86362001); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?utf-8?B?eHl4SEYvYXBHeFFjeERpUkxXQWZGRnN2YW9LNGRYWUp4S3hMYWVDR0dpZGdh?= =?utf-8?B?TDR0c3F6enhGR2lyYS9pa3VRcUpOaFdldVpSUTdLZVp3K0Q4Ylo1VGlkaGVO?= =?utf-8?B?dytkWVQwUEJ0YWhuNTdFaUdqYitFVkFEZmw3TllWSkZra3lFUm1kQmJFL3BW?= =?utf-8?B?cXdUb2ptejhLd0phSVdHckhBdlVuQm93Q2lxQnVGazQySEdnaDlZaGJuV3hz?= =?utf-8?B?WUVzVm9MSW9rNkNNWWV4ckZOTmpXdUJsMVBlT05oMmN3SW43bUk0QjBtQ1gr?= =?utf-8?B?UVdJVWRvc1djSzljeUM1NnN5VHQvVGRMaERqaEFPUlNnZnRrdnN1NVJKeWVF?= =?utf-8?B?TkUrRDNCcHhXdVdVOWRkSzNya1hWNnVVbEVTbDM4d1M4UXlxYjdPMTZYM2Nl?= =?utf-8?B?K2lzbGRGU0txYXk5ZGlicHNuRVRmb1pWdHFsTGxlMHVZRnhxZms0K1lQaHF4?= =?utf-8?B?UWxzN3ZPS0RKekd4bWd0TXFyUmlhSWNicUc2ZGZPQ2FOaHJUMFZCRzVWMDVr?= =?utf-8?B?cWdReGh2ZzdETmhiNGJRcDVpckZTdXNUbXYvLzJUMEdqb0x3cTF5TE4vUUYx?= =?utf-8?B?WjB1T25POTdqNGJWRlRwUmZMM0JPalZQRDIzdXZTVVNsZTdabXd1dFR0SGZB?= =?utf-8?B?NHlnRnF2SnZQTklGZll6dnQrWktLdTE0cExpa1lEajBrb3VZYmxMK1pEQ24y?= =?utf-8?B?bVB5cFh6QU1CUmVCeVVVMS8zcE9VUllTMVRlaldmZ2hWZzFGeExkUjd3S0p4?= =?utf-8?B?ZG85cGI3ZERwTzRIMUwvamJoa3MyaE02b0pqTERqNlZDUW5wNTU2N1pUWmpY?= =?utf-8?B?RXBnZkVIVmxZR25PVFJOUm8zcU5OZ1NqR2ZPaXNPci9HYnBDd3hDZ1FjY3Jl?= =?utf-8?B?US9JNDRuNFRzQmN3cGVNN1RnT2dobDQwbWxFOGcydTdQU3ZrOGoxSFRaSm9I?= =?utf-8?B?aUt0dnJrMENFQ29GL0ZSUE9iNlNrTzdycGtoWFdGVUREOHIxaDMyZFM0bW5P?= =?utf-8?B?V1k1TzlRYW5WMk9yOTg1Qy9iQ1RZYkowREJxZjN2cG1nek93dmFLZE5FUk12?= =?utf-8?B?ajJxTzBiN0VrWEdpVVQ0ajVyekdtR29OZkhTUzg3bGoxYk15SWtjc0hVRnBv?= =?utf-8?B?aFZpZFF1NFdyQnJEdkRLaGhaRGlaR3FvTjVMbnBadUdwcml4cHVmTzRsM0VB?= =?utf-8?B?KzhRYlZjTzdPSHJPSkhpdzRDbEtuampEOHVlTlBuL1N6T3UwSFZCd0dJZURw?= =?utf-8?B?UVZRM0FwNTViamFyWmRESEFHOWFJc0tKQUJDckp2NkhrUmcxazZUZDNwdGE2?= =?utf-8?B?VTFJSG55R2xOVDZqR20xNjk3SncvSDF0emtzTWRZdFlVNzcycnRqRXlGV2oy?= =?utf-8?B?alBYUndXRmNyajhEWEthMDNQWUlQM0hLOHhzSUtmTkUwaGVtVjBHNnZBazYy?= =?utf-8?B?ZEpaaldmRWY0bHJsY09kRTY0dWxmOWViMnFaMGJWa0l3Sjk4WnJFM0ZlNUR0?= =?utf-8?B?MjF5Z2xPL0k5ZTg0d2cvOVZMWjRtK0FrRjZaQm4yRFBZOTZ1em9VbjFCR0l2?= =?utf-8?B?bkl2dGg5VFIxa3VueFdhRzM1SGZTTDZTUmt5V3RpbktBQVc0eDdNOXArOGE2?= =?utf-8?B?T2NWN1Z4Z3lnNUo4bEtpREVxeE96eWs3UWVCbjJMSGZkT0xXSzdZMDlVQVJX?= =?utf-8?B?eWVjbjJYNEdUTFkvTDFPY3J2S1lEa2h6Y2REZzJaelJpcHZ4R25tR0xFZjRv?= =?utf-8?Q?KGbhSSnqYF540kdJGDGnpCgAWVKK5hxz21kvKE9?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: intopix.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PR3P192MB0748.EURP192.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 81a8d0ce-fe5b-4743-95da-08d921c245df
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2021 10:20:52.7825 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5f9168c7-cdac-4b23-9509-c278399e3c1f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: pREq9JSOdGuIHSVMalvtsHqfE729ZxGz6cFWdLzHsNPf4SLB2RGP/MUZNhKTd2x9
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXP192MB1392
X-MDID: 1622197255-RCawJFYQ3-tJ
Archived-At: 
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 May 2021 10:21:05 -0000

SGkgQ2hyaXN0ZXIsDQoNClRoYW5rcyBmb3IgdGhlIHF1aWNrIHJlc3BvbnNlLCB3ZSByZWFsbHkg
YXBwcmVjaWF0ZSB5b3VyIHRpbWUuDQoNClNvLCBsZXQgbWUgZWxhYm9yYXRlIGEgYml0Og0KDQo+
PiBGaXJzdCwgcmVnYXJkaW5nIFJGQyA4NDUwLCB0aGF0IHNwZWNpZmljYXRpb24gd2FzIHByb2Jh
Ymx5IG5ldmVyIHJldmlld2VkIGJ5IHRoZSBTRFAgZGlyZWN0b3JhdGUsIHNvIEkgY2FuJ3QgcmVh
bGx5IGNvbW1lbnQgb24gdGhhdC4gQnV0LCBJIHNlZSB0aGF0IHRoZSBSRkMgZS5nLiwgc2F5cyBu
b3RoaW5nIGFib3V0IHdoZXRoZXIgdGhlIFNEUCBpbmRpY2F0ZXMgc2VuZGluZyBvciByZWNlaXZp
bmcgY2FwYWJpbGl0aWVzLg0KDQpPaywgSSB1bmRlcnN0YW5kIHRoYXQgUkZDIDg0NTAgbWlnaHQg
bm90IGJlIGVudGlyZWx5IGNsZWFyIG9yIHdlbGwgd3JpdHRlbiBvbiB0aGUgU0RQIHBhcnQuDQoN
Cj4+IFNlY29uZCwgbm9ib2R5IG1hbmRhdGVzIHlvdSB0byB1c2UgU0RQLCBhbmQgbW9zdCBwYXJ0
IG9mIHRoZSBzcGVjIGlzIHByb3RvY29sIGluZGVwZW5kZW50LiBCdXQsIHRoZSAiU0RQIE9mZmVy
L0Fuc3dlciIgc2VjdGlvbiBkZXNjcmliZXMgdGhlIFNEUCBvZmZlci9hbnN3ZXIgcHJvY2VkdXJl
cywgKklGKiB5b3UgY2hvb3NlIHRvIHVzZSB0aGF0IG1lY2hhbmlzbSBmb3IgbmVnb3RpYXRpbmcg
dGhlIHNlc3Npb24uDQoNCk9rLiBUaGF0IEkgdW5kZXJzdGFuZC4gSW4gb3VyIGNhc2UsIFNEUCBh
cyB0aGUgc2Vzc2lvbiBwcm90b2NvbCBpcyBub3QgY3JpdGljYWwsIGJ1dCBzdGlsbCBhIG5pY2Ug
dG8gaGF2ZS4gRG8geW91IGFncmVlPyBPciBkbyB5b3UgcmVjb21tZW5kIHdlIHJlbW92ZSB0aGUg
U0RQIG9mZmVyL2Fuc3dlciBzZWN0aW9uPw0KDQpXaGF0IHdlIGRvIG5lZWQgdG8gc2F5IGlzIGhv
dyB0byBtYXAgcGFyYW1ldGVycyBpbnRvIGFuIFNEUC1jb21wbGlhbnQgZm9ybWF0IGRlc2NyaXB0
aW9uLCBmb3IgdGhlIHNhbWUgcmVhc29ucyBhcyBSRkMgODQ1MCBhbmQgbWFueSBvdGhlciB2aWRl
byBwYXlsb2FkIFJGQydzIChWUDgsIFZQOSwgSC4yNjQvQVZDLCBILjI2NS9IRVZDLCBldGMpLiBU
aGlzIGFsbG93cyB1c2luZyBtYW55IG90aGVyIHNlc3Npb24gbmVnb3RpYXRpb24gcHJvdG9jb2xz
IHRoYXQgcmVseSBvbiB0aGUgU0RQIGRlc2NyaXB0aW9uLg0KDQo+PiBUaGlyZCAuLi4uDQoNCkkg
YmVsaWV2ZSB3aGF0IGlzIHZlcnkgaW1wb3J0YW50IHRvIGV4cGxhaW4gaXMgdGhhdCBhbGwgb2Yg
b3VyIHBhcmFtZXRlcnMgYXJlIGRlY2xhcmF0aXZlLCBtZWFuaW5nIHRoYXQgdGhleSBkZXNjcmli
ZSBleGFjdCBiaXRzdHJlYW0gcHJvcGVydGllcywgYW5kIG5vdCByZWNlaXZlciBjYXBhYmlsaXRp
ZXMuIFRoZSBTRFAgcGFyYW1ldGVycyBjYW4gYmUgdXNlZCB0byBjb21tdW5pY2F0ZSBiZXR3ZWVu
IHNlbmRlci9yZWNlaXZlciB3aGF0IHRoZXkgd2lzaCB0byBleGNoYW5nZSBiZWZvcmUgc2VuZGlu
ZyBhY3R1YWwgcGF5bG9hZCwgYnV0IG5vbmUgb2YgdGhlc2UgcGFyYW1ldGVycyBvciB2YWx1ZXMg
YXJlICJkb3duZ3JhZGFibGUiIG9yICJpbmNsdXNpdmUgY2FwYWJpbGl0eSBzZXRzIi4gWFMgZG9l
cyBub3QgaGF2ZSBzdWNoIGNvbmNlcHRzLCBhcyBpdCBpcyBhIGxvdy1jb21wbGV4aXR5IGNvZGVj
LCBpbnRlbmRlZCBwcmltYXJpbHkgdG8gcmVwbGFjZSB1bmNvbXByZXNzZWQgdmlkZW8gc3RyZWFt
cy4NCg0KU29tZWhvdywgdGhpcyByYWlzZXMgdGhlIGZvbGxvd2luZzoNCg0KWC4xIEdlbmVyaWMg
U0RQIENvbnNpZGVyYXRpb25zDQogIEkgYmVsaWV2ZSBoZXJlIHdlIGV4cGxhaW4gdGhhdCBwYXJh
bWV0ZXJzIGFyZSBkZWNsYXJhdGl2ZSBhbmQgcmVwcmVzZW50IGJpdHN0cmVhbS9wYXlsb2FkIHZh
bHVlcy9zZXR0aW5ncy4gU28gYm90aCBzaWRlcyBjYW4gdXNlIHRoZXNlIHRvIGluZGljYXRlIHdo
YXQgdGhlIHBheWxvYWQgd2lsbCBsb29rIGxpa2UuDQoNClguMi4gIEdlbmVyYXRpbmcgdGhlIElu
aXRpYWwgU0RQIE9mZmVyDQogIE5vdCBtdWNoIHRvIHNheSBoZXJlLiBBcyBJIHVuZGVyc3RhbmQg
YW4gU0RQIHNlc3Npb24gY2FuIGJlIGluaXRpYXRlZCBmcm9tIGVpdGhlciByZWNlaXZlciBvciBz
ZW5kZXIgc2lkZXM/IFNvLCB0aGV5IGp1c3Qgc2VuZCBhIHZhbGlkIG1lZGlhIGRlc2NyaXB0aW9u
IG9mIHRoZSBjb250ZW50IHRoZXkgd2FudCB0byBleGNoYW5nZS4gSWYgZWl0aGVyIHNpZGUgY2Fu
bm90IGhhbmRsZSBjZXJ0YWluIHBheWxvYWQgc2V0dGluZ3MsIHRoZW4gaXQgc2hvdWxkIHJlamVj
dCB0aGUgb2ZmZXIgKG9yIGFuc3dlcikuIEFuIG9mZmVyZXIganVzdCBzZW5kcyB3aGF0IGl0IHdh
bnRzIHRvIHJlY2VpdmUgb3Igc2VuZC4NCg0KWC4zLiAgR2VuZXJhdGluZyB0aGUgU0RQIEFuc3dl
cg0KICBJIGRvbid0IHRoaW5rIHRoZXJlIGlzIGFueXRoaW5nIHNwZWNpYWwgdG8gbWVudGlvbiBo
ZXJlPyBUaGUgYW5zd2VyZXIgdGFrZXMgdGhlIGRlY2xhcmF0aXZlIHBhcmFtZXRlcnMgYW5kIGVp
dGhlciBhY2NlcHRzIG9yIHJlamVjdHMgdGhlIHNlc3Npb24uIEl0IHNob3VsZCBOT1QgbW9kaWZ5
IHRoZSBvZmZlciBpbiBhbnkgd2F5Lg0KDQpYLjQuICBPZmZlcmVyIFByb2Nlc3Npbmcgb2YgdGhl
IFNEUCBBbnN3ZXINCiAgSSBkb24ndCB0aGluayB0aGVyZSBpcyBhbnl0aGluZyBzcGVjaWFsIHRv
IG1lbnRpb24gaGVyZT8gSWYgdGhlIGFuc3dlciBhY2NlcHRlZCB0aGUgb2ZmZXIsIHRoZW4gdGhl
IHN0cmVhbSBjYW4gc3RhcnQuDQoNClguNS4gIE1vZGlmeWluZyB0aGUgU2Vzc2lvbg0KICBNb2Rp
ZnlpbmcgdGhlIHNlc3Npb24gaXMgcG9zc2libGUsIGJ1dCB0aGlzIGlzIHZlcnkgaW1wbGVtZW50
YXRpb24gc3BlY2lmaWMuIEJhc2ljYWxseSwgbW9kaWZ5aW5nIGEgc2Vzc2lvbiBpcyB2ZXJ5IHNp
bWlsYXIgdG8gY3JlYXRpb24gb2YgYSBuZXcgc2Vzc2lvbi4gQm90aCBzaWRlcyBzaG91bGQgYWdy
ZWUgb24gdGhlIHBheWxvYWQgdGhleSB3aWxsIGV4Y2hhbmdlLg0KDQoNCkknbSBzb3JyeSB0byBk
cmFnIHRoaXMgb3V0LCBidXQgSSB0aGluayB0aGF0IGhhdmluZyB0aGlzIGNvbnZlcnNhdGlvbiBi
eSBlbWFpbCBpcyBtb3JlIGVmZmljaWVudCB0aGFuIHBvc3RpbmcgZHJhZnRzIPCfmIogSSBhcHBy
ZWNpYXRlIHlvdXIgZmVlZGJhY2suDQoNClRpbS4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KRnJvbTogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u
LmNvbT4gDQpTZW50OiBGcmlkYXkgMjggTWF5IDIwMjEgMTA6MzkNClRvOiBUaW0gQnJ1eWxhbnRz
IDxUQlJAaW50b3BpeC5jb20+OyBUaG9tYXMgUmljaHRlciA8dGhvbWFzLnJpY2h0ZXJAaWlzLmZy
YXVuaG9mZXIuZGU+OyBhdnRAaWV0Zi5vcmcNCkNjOiBKZWFuLUJhcHRpc3RlIExvcmVudCA8amIu
bG9yZW50QGludG9waXguY29tPg0KU3ViamVjdDogUkU6IFtBVlRDT1JFXSBTRFAgZGlyZWN0b3Jh
dGUgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtanBlZ3hzLTEzDQoNCkhpLA0KDQpG
aXJzdCwgcmVnYXJkaW5nIFJGQyA4NDUwLCB0aGF0IHNwZWNpZmljYXRpb24gd2FzIHByb2JhYmx5
IG5ldmVyIHJldmlld2VkIGJ5IHRoZSBTRFAgZGlyZWN0b3JhdGUsIHNvIEkgY2FuJ3QgcmVhbGx5
IGNvbW1lbnQgb24gdGhhdC4gQnV0LCBJIHNlZSB0aGF0IHRoZSBSRkMgZS5nLiwgc2F5cyBub3Ro
aW5nIGFib3V0IHdoZXRoZXIgdGhlIFNEUCBpbmRpY2F0ZXMgc2VuZGluZyBvciByZWNlaXZpbmcg
Y2FwYWJpbGl0aWVzLg0KDQpTZWNvbmQsIG5vYm9keSBtYW5kYXRlcyB5b3UgdG8gdXNlIFNEUCwg
YW5kIG1vc3QgcGFydCBvZiB0aGUgc3BlYyBpcyBwcm90b2NvbCBpbmRlcGVuZGVudC4gQnV0LCB0
aGUgIlNEUCBPZmZlci9BbnN3ZXIiIHNlY3Rpb24gZGVzY3JpYmVzIHRoZSBTRFAgb2ZmZXIvYW5z
d2VyIHByb2NlZHVyZXMsICpJRiogeW91IGNob29zZSB0byB1c2UgdGhhdCBtZWNoYW5pc20gZm9y
IG5lZ290aWF0aW5nIHRoZSBzZXNzaW9uLg0KDQpUaGlyZCwgSSBkb24ndCB0aGluayB5b3UgbmVl
ZCB2ZXJ5IG11Y2ggdGV4dC4gVGhlIGltcG9ydGFudCB0aGluZyBpcyB0byBzYXkgd2hhdCBpcyBw
bGFjZWQgaW4gb2ZmZXJzIGFuZCBhbnN3ZXJzLCB3aGV0aGVyIHRoZXJlIGFyZSBjb25zdHJhaW50
cyB3aGVuIGdlbmVyYXRpbmcgdGhlIGFuc3dlciwgYW5kIHdoZXRoZXIgdGhlcmUgYXJlIGNvbnN0
cmFpbnRzIHdoZW4gaXQgY29tZXMgdG8gbW9kaWZ5aW5nIHRoZSBzZXNzaW9uLiBBbmQsIHlvdSBk
byBOT1QgIG5lZWQgdG8gc3BlY2lmeSBIT1cgdG8gbW9kaWZ5IGEgc2Vzc2lvbiwgYnV0IHdoZXRo
ZXIgdGhlcmUgYXJlIHBheWxvYWQtc3BlY2lmaWMgY29uc3RyYWludHMgd2hlbiBkb2luZy4NCg0K
UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206
IFRpbSBCcnV5bGFudHMgPFRCUkBpbnRvcGl4LmNvbT4NClNlbnQ6IHBlcmphbnRhaSAyOC4gdG91
a29rdXV0YSAyMDIxIDkuNDkNClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJl
cmdAZXJpY3Nzb24uY29tPjsgVGhvbWFzIFJpY2h0ZXIgPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v
ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX190aG9tYXMucmljaHRlci00MGlpcy5mcmF1bmhv
ZmVyLmRlJmQ9RHdJRkFnJmM9ZXVHWnN0Y2FURGxsdmltRU44YjdqWHJ3cU9mLXY1QV9DZHBnblZm
aWlNTSZyPUxUeFVHdWtMQ0VmRVVkb19icTA0OFEmbT1nZkI0UEYtdlZCVy1IVnhjU3hDeDA3TENo
UTFDU2VwWU4zSm51dlBadmhnJnM9V2cwOGkzMjEzYkN5UDBZYjhIajVpaHBCV2otZGxyVm5LRGRq
Z2dPSmJxQSZlPT47IGF2dEBpZXRmLm9yZw0KQ2M6IEplYW4tQmFwdGlzdGUgTG9yZW50IDxqYi5s
b3JlbnRAaW50b3BpeC5jb20+DQpTdWJqZWN0OiBSRTogW0FWVENPUkVdIFNEUCBkaXJlY3RvcmF0
ZSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1qcGVneHMtMTMNCg0KSGkgQ2hyaXN0
ZXIsDQoNCkknbSBhIGxpdHRsZSBiaXQgc3R1Y2sgaW4gaG93IHRvIHJlc29sdmUgYW5kIGFkZHJl
c3MgeW91ciBjb21tZW50cy4gT24gb25lIGhhbmQgSSB1bmRlcnN0YW5kIHRoYXQgd2Ugd2FudCB0
aGUgdGV4dCB0byBiZSBjbGVhciwgYnV0IG9uIHRoZSBvdGhlciBoYW5kIHdlIGRvIG5vdCB3YW50
IHRvIHJlcGVhdCBTRFAgc3BlY2lmaWNzIHRvbyBtdWNoLiBTRFAgaXMganVzdCBvbmUgd2F5IHRv
IG5lZ290aWF0ZSBhIHNlc3Npb24sIGFuZCBpbiB0aGUgY2FzZSBvZiBYUyBpdCBpcyBub3QgdGhl
IG1vc3QgY29tbW9ubHkgdXNlZCBvbmUuIFhTIGlzIG5vdCByZWFsbHkgaW50ZW5kZWQgZm9yIHRo
ZSBjbGFzc2ljYWwgdmlkZW8tY2FsbCBjYXNlLCBidXQgcmF0aGVyIHRvIHN0cmVhbSBoaWdoLXF1
YWxpdHkgdmlkZW8gY29udGVudCBpbiBhIHByb2Zlc3Npb25hbCBlbnZpcm9ubWVudC4gSXQgY2Fu
IGJlIHVzZWQgZm9yIHZpZGVvIGNvbmZlcmVuY2luZywgYnV0IGJldHRlciBzdWl0ZWQgY29kZWNz
IGV4aXN0IGZvciB0aGF0IHVzZS1jYXNlLg0KDQpIb3dldmVyLCB3aGF0IGlzIGltcG9ydGFudCB0
byBsYXkgb3V0IGNvcnJlY3RseSBpcyB0aGUgbWFwcGluZyBvZiB0aGUgbWVkaWEgcGFyYW1ldGVy
cyBpbnRvIHRoZSBhPWZtdHAgZmllbGQgb2YgU0RQLCBiZWNhdXNlIHRoaXMgaXMgYWN0dWFsbHkg
dXNlZCBieSBtYW55IG90aGVyIHByb3RvY29scyAoc28sIGp1c3QgdGhlIG1lZGlhIGRlc2NyaXB0
aW9uIHBhcnQgb2YgU0RQIGlzIHVzZWQpLg0KDQpPcmlnaW5hbGx5LCB3ZSBiYXNlZCBvdXIgZHJh
ZnQgdGV4dCBvbiBSRkMgODQ1MCAoVkMtMiBIUSBSVFAgUGF5bG9hZCkuIEluIHRoYXQgcmVzcGVj
dCwgd2hhdCBpcyB3cml0dGVuIHRoZXJlIGtpbmQgb2YgZml0cyBleGFjdGx5IHdoYXQgd2Ugd2Fu
dCB3aXRoIFhTLiBHaXZlbiB0aGF0IHRoaXMgaXMgYSBwdWJsaXNoZWQgUkZDLCB3ZSBhcmUgcHV6
emVsZWQgYSBiaXQgYXMgdG8gd2h5IG91ciBkcmFmdCB3b3VsZCBuZWVkIHRvIGVsYWJvcmF0ZSBz
byBleHRlbnNpdmVseSBvbiBTRFAuIEZvciBzdXJlLCB3ZSdkIGxpa2UgdG8gYWxsb3cgU0RQIG9m
ZmVyL2Fuc3dlciBuZWdvdGlhdGlvbiB3aXRoIFhTLiBCdXQgdGhpcyBpcyB2ZXJ5IHNpbXBsZTog
ZWFjaCBzaWRlIHRlbGxzIHRoZSBvdGhlciBzaWRlIHdoYXQgaXQgc3VwcG9ydHMsIGFuZCB0aGF0
J3MgaXQuIEluIFhTIHRoZSBwYXJhbWV0ZXJzIGFyZSBkZWNsYXJhdGl2ZSwgbWVhbmluZyAoYXQg
bGVhc3QgdGhhdCdzIHdoYXQgd2Ugd2FudCB0byBleHByZXNzKSB0aGF0IGVhY2ggcGFyYW1ldGVy
IGlzIHJlcHJlc2VudHMgYW4gZXhhY3QgdmFsdWUgYW5kIGlzIG5vdCAiaW5jbHVzaXZlIiBpbnRv
IGEgcmFuZ2Ugb2YgbGVzc2VyIHZhbHVlcy4gSW4gb3RoZXIgd29yZHMsIHRoZSBvdGhlciBzaWRl
IGNhbm5vdCBleHBlY3QgdGhhdCBhICJsZXNzZXIiIHZhbHVlIG9mIGEgcGFyYW1ldGVyIGNhbiB3
b3JrLg0KDQpZb3VyIHByb3Bvc2VkIHN0cnVjdHVyZSBpcyBqdXN0IHRvIGVsYWJvcmF0ZSBhbmQg
b3V0IG9mIHNjb3BlLiBBcyBzdWNoLCBJIHdvdWxkIGFzayB5b3UgdG8gY29uc2lkZXIgdGhlIGV4
YW1wbGUgb2YgUkZDIDg0NTAgKHdoZXJlIHRoZSB1c2UtY2FzZSBhbmQgcHVycG9zZSBtYXRjaGVz
IHRoYXQgb2Ygb3VyIGRyYWZ0KS4gRm9yIGV4YW1wbGU6IFdoeSBkbyB3ZSBuZWVkIHRvIHN0YXRl
IGFueXRoaW5nIHNwZWNpZmljIG9uICJNb2RpZnlpbmcgdGhlIFNlc3Npb24iPyBJc24ndCB0aGlz
IGxheWVkIG91dCBieSBTRFAgb24gaG93IHRvIG1vZGlmeSBhIHNlc3Npb24/IFRoZXJlJ3Mgbm90
aGluZyBzcGVjaWZpYyB0byBiZSBwdXQgaW4gb3VyIGRyYWZ0ICh3ZSBkbyBub3Qgd2FudCB0byBw
cmV2ZW50LCBub3Qgc3VnZ2VzdCB0aGlzIGZ1bmN0aW9uYWxpdHkpLg0KDQpJIGhvcGUgeW91IGNh
biB1bmRlcnN0YW5kIG91ciBkaWZmaWN1bHR5IHdpdGggeW91ciByZW1hcmtzIGFuZCBjb21tZW50
cy4gT3VyIHByb3Bvc2FsIGFzIHN1Y2ggaXMgdG8ga2VlcCB0aGUgdGV4dCBhYm91dCBTRFAgdmVy
eSBzaG9ydCBhbmQgc2ltcGxlLiBUaGUgUlRQIFBheWxvYWQgZHJhZnQgY2FuIGJlIHVzZWQgd2l0
aCBTRFAsIGJ1dCBpdCdzIGNlcnRhaW5seSBub3QgdGhlIG9ubHkgd2F5Lg0KDQpJIHdpbGwgYmUg
cHJlcGFyaW5nIGFuIHVwZGF0ZWQgZHJhZnQgd2hpY2ggdHJpZXMgdG8gYmUgdmVyeSBtaW5pbWFs
IG9uIHRoZSBTRFAgc3BlY2lmaWNzLiBVbmxlc3MgYW55dGhpbmcgaXMgdGVjaG5pY2FsbHkgd3Jv
bmcsIEkgcmVhbGx5IGhvcGUgeW91IGNhbiBhZ3JlZSB0byBpdCBhbmQgbW92ZSBmb3J3YXJkIHdp
dGggdGhlIHB1YmxpY2F0aW9uIHByb2Nlc3MuDQoNCkJlc3QgcmVnYXJkcywNClRpbS4NCg0KDQot
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogYXZ0IDxhdnQtYm91bmNlc0BpZXRmLm9y
Zz4gT24gQmVoYWxmIE9mIENocmlzdGVyIEhvbG1iZXJnDQpTZW50OiBXZWRuZXNkYXkgMjYgTWF5
IDIwMjEgMTg6NDMNClRvOiBUaG9tYXMgUmljaHRlciA8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29m
cG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3Rob21hcy5yaWNodGVyLTQwaWlzLmZyYXVuaG9m
ZXIuZGUmZD1Ed0lGQWcmYz1ldUdac3RjYVREbGx2aW1FTjhiN2pYcndxT2YtdjVBX0NkcGduVmZp
aU1NJnI9TFR4VUd1a0xDRWZFVWRvX2JxMDQ4USZtPWdmQjRQRi12VkJXLUhWeGNTeEN4MDdMQ2hR
MUNTZXBZTjNKbnV2UFp2aGcmcz1XZzA4aTMyMTNiQ3lQMFliOEhqNWlocEJXai1kbHJWbktEZGpn
Z09KYnFBJmU9PjsgYXZ0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0FWVENPUkVdIFNEUCBkaXJl
Y3RvcmF0ZSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1qcGVneHMtMTMNCg0KVGhp
cyBpcyBhIHN0cnVjdHVyZSB0aGF0IGlzIHR5cGljYWxseSB1c2VkIGZvciBTRFAgb2ZmZXIvYW5z
d2VyIHByb2NlZHVyZXM6DQoNClguICBTRFAgT2ZmZXIvQW5zd2VyIFByb2NlZHVyZXMNCiAgICAg
WC4xLiAgR2VuZXJpYyBTRFAgQ29uc2lkZXJhdGlvbnMNCgk8SGVyZSB5b3UgY2FuIGRlc2NyaWJl
IHRoaW5ncyB3aGljaCBhcHBseSB0byBib3RoIG9mZmVycyBhbmQgYW5zd2Vycz4NCiAgICAgWC4y
LiAgR2VuZXJhdGluZyB0aGUgSW5pdGlhbCBTRFAgT2ZmZXINCgk8SGVyZSB5b3UgZGVzY3JpYmUg
aG93IHRoZSBpbml0aWFsIFNEUCBvZmZlciBmb3IgdGhlIHNlc3Npb24gaXMgZ2VuZXJhdGVkPg0K
ICAgICBYLjMuICBHZW5lcmF0aW5nIHRoZSBTRFAgQW5zd2VyDQoJPEhlcmUgeW91IGRlc2NyaWJl
IGhvdyB0aGUgYW5zd2VyZXIgZ2VuZXJhdGVzIHRoZSBTRFAgYW5zd2VyLCBpbmNsdWRpbmcgd2hl
dGhlciBwYXJhbWV0ZXJzL3BhcmFtZXRlciB2YWx1ZXMgbmVlZCB0byBiZSBhIHN1YnNldCBvZiB0
aGUgcGFyYW1ldGVycy9wYXJhbWV0ZXIgdmFsdWVzIGluIHRoZSBvZmZlciBldGM+DQogICAgIFgu
NC4gIE9mZmVyZXIgUHJvY2Vzc2luZyBvZiB0aGUgU0RQIEFuc3dlcg0KICAgICA3LjUuICBNb2Rp
ZnlpbmcgdGhlIFNlc3Npb24NCgk8SGVyZSB5b3UgZGVzY3JpYmUgY29uc3RyYWludHMgcmVsYXRl
ZCB0byBtb2RpZmljYXRpb24gb2YgdGhlIHNlc3Npb24sIGluY2x1ZGluZyB3aGV0aGVyIHRoZXJl
IGFyZSBjZXJ0YWluIHBhcmFtZXRlcnMvcGFyYW1ldGVyIHZhbHVlcyB0aGF0IHlvdSBjYW5ub3Qg
bW9kaWZ5IGV0Yz4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCkZyb206IGF2dCA8YXZ0LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBD
aHJpc3RlciBIb2xtYmVyZw0KU2VudDoga2Vza2l2aWlra28gMjYuIHRvdWtva3V1dGEgMjAyMSAx
OS4zOA0KVG86IFRob21hcyBSaWNodGVyIDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j
b20vdjIvdXJsP3U9aHR0cC0zQV9fdGhvbWFzLnJpY2h0ZXItNDBpaXMuZnJhdW5ob2Zlci5kZSZk
PUR3SUNBZyZjPWV1R1pzdGNhVERsbHZpbUVOOGI3alhyd3FPZi12NUFfQ2RwZ25WZmlpTU0mcj1M
VHhVR3VrTENFZkVVZG9fYnEwNDhRJm09THRlZlFpTGhkclh3VXljYWg3Wm1zYXlrX2R0SEYtaE1F
QndIbzZEcGV0MCZzPS1UTzFRZjdsMV9xYzRrbFJLdmJ1VzhfZUQ0TDhmODVPQjVEYWhiMkxRR0Um
ZT0+OyBhdnRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQVZUQ09SRV0gU0RQIGRpcmVjdG9yYXRl
IHJldmlldyBvZiBkcmFmdC1pZXRmLXBheWxvYWQtcnRwLWpwZWd4cy0xMw0KDQpIaSwNCg0KPj4g
VW5mb3J0dW5hdGVseSBJIGRvbid0IHRoaW5rIHdoYXQgeW91IGV4cGxhaW4gYWJvdmUgaXMgdmVy
eSBjbGVhciBpbiANCj4+IHRoZSB0ZXh0Lg0KPj4gDQo+PiBDb25zaWRlciB0aGUgZm9sbG93aW5n
Lg0KPj4gDQo+PiBUaGUgb2ZmZXJlciBzZW5kcyBhbiBvZmZlci4gVGhlIG9mZmVyZXIgc3BlY2lm
aWVzIHRoZSBjaGFyYWN0ZXJpc3RpY3MgDQo+PiB0aGF0IHRoZSBvZmZlcmVyIHdhbnRzIHRvIHJl
Y2VpdmUuIFNpbWlsYXJseSwgdGhlIGFuc3dlciBzcGVjaWZpZXMgDQo+PiB0aGUgY2hhcmFjdGVy
aXN0aWNzIHRoYXQgdGhlIGFuc3dlcmVyIHdhbnRzIHRvIHJlY2VpdmUgLSB0aGUgYW5zd2VyZXIg
DQo+PiBkb2VzIE5PVCBzcGVjaWZ5IHdoYXQgaXQgaXMgZ29pbmcgdG8gc2VuZC4gd2hpY2ggSSB0
aGluayB0aGUgdGV4dCBpcyANCj4+IGN1cnJlbnRseSBkZXNjcmliaW5nLg0KPg0KPiBTb3JyeSB0
byBzb3VuZCBjb25mdXNlZCwgYnV0IG1heWJlIHlvdSBjb3VsZCBleHBsYWluIGEgYml0IGJldHRl
ci4gVG8gbXkgdW5kZXJzdGFuZGluZywgaXQgaXMgdGhlIG9mZmVyZXIgdGhhdCBkZXNjcmliZXMg
d2hhdCBpdCBvZmZlcnMgdG8gc2VuZCwgYW5kIG5vdCB0aGUgb3RoZXIgd2F5IGFyb3VuZD8gDQo+
IE1heWJlIEkgbWlzdW5kZXJzdGFuZCBzb21ldGhpbmcgdmVyeSBmdW5kYW1lbnRhbD8gU29ycnkg
dG8gYXNrIHRoZXNlIGVsZW1lbnRhcnkgcXVlc3Rpb25zLCBidXQgdGhpcyBpcyBpbXBvcnRhbnQg
Zm9yIHRoZSB0ZXh0Lg0KDQpJbiBTRFAgT2ZmZXIvQW5zd2VyLCB0aGUgZGVmYXVsdCBpcyB0byBp
bmRpY2F0ZSB3aGF0IHlvdSBhcmUgd2lsbGluZyB0byBSRUNFSVZFIDopDQoNClR5cGljYWxseSB5
b3VyIHJlY2VpdmluZyBjYXBhYmlsaXRpZXMgYWxzbyBpbXBsaWNpdGx5IGluZGljYXRlIHdoYXQg
eW91IGFyZSBhYmxlIHRvIHNlbmQuIEZvciBleGFtcGxlLCBpZiBJIGFtIGluZGljYXRpbmcgdGhh
dCBJIGFtIHdpbGxpbmcgdG8gcmVjZWl2ZSBjb2RlYyBYIGl0IG5vcm1hbGx5IG1lYW5zIHRoYXQg
SSBhbSBhbHNvIGFibGUgdG8gc2VuZCBjb2RlYyBYLg0KDQogQnV0LCB0aGVyZSBhcmUgY2FzZXMg
d2hlcmUgdGhhdCBpcyBub3QgdHJ1ZSwgZXNwZWNpYWxseSB3aGVuIGl0IGNvbWVzIHRvIHZpZGVv
IGNvZGVzIHdoZXJlIHlvdSB0eXBpY2FsbHkgaGF2ZSBtb3JlIHBhcmFtZXRlcnMgYXNzb2NpYXRl
ZCB3aXRoIHRoZSBjb2RlYywgYW5kIG9uZSBuZWVkcyB0byBleHBsaWNpdGx5IGluZGljYXRlIHNl
bmRpbmcgY2FwYWJpbGl0aWVzLiANCg0KLS0tDQoNCj4+ICJUaGUgcmVjZWl2ZXIgU0hBTEwgaWdu
b3JlIGFueSB1bnJlY29nbml6ZWQgcGFyYW1ldGVyIG9yIGludmFsaWQgDQo+PiBwYXJhbWV0ZXIg
dmFsdWUuIg0KPj4gDQo+PiBGaXJzdCwgSW4gbXkgb3BpbmlvbiBpbnZhbGlkIHBhcmFtZXRlcnMg
dmFsdWVzIHNoYWxsIHRyaWdnZXIgYW4gZXJyb3IuDQo+PiANCj4+IFNlY29uZCwgd2hhdCBpcyBh
biB1bnJlY29nbml6ZWQgcGFyYW1ldGVyPw0KPg0KPiBJIHdvbmRlciB3aHkgd2UgbmVlZCB0byBz
cGVjaWZ5IHRoaXMsIGkuZS4gd2hhdCBhIHJlY2VpdmUgZG9lcyBhYm91dCANCj4gcGFyYW1ldGVy
cyBpdCBkb2VzIG5vdCByZWNvZ25pemU/IEVzc2VudGlhbGx5LCB0aGlzIGlzIGEgcHJvYmxlbSBv
ZiANCj4gImZvcmV3YXJkIGNvbXBhdGliaWxpdHkiLiBXb3VsZG4ndCBpdCBiZSBhIG1hdHRlciBv
ZiBpbXBsZW1lbnRhdGlvbiB3aGV0aGVyIHRoZSByZWNlaXZlciBhY2NlcHRzIGFuIG9mZmVyIChu
b3RlIHdlbGwsIHRoZSByZWNlaXZlciksIGFuZCBhdHRlbXB0cyB0byBkZWNvZGUgYSBzdHJlYW0g
b24gYSAiYmVzdCBlZmZvcnQiIGJhc2lzLCBrZWVwaW5nIGluIG1pbmQgdGhhdCB0aGUgc3RyZWFt
IGl0c2VsZiBpbmNsdWRlcyBhZGRpdGlvbmFsIG1lYW5zIHRvIGlkZW50aWZ5IHJlcXVpcmVkIGNh
cGFiaWxpdGllcyBuZWNlc3NhcnkgZm9yIGEgc3VjY2Vzc2Z1bCBkZWNvZGUuDQo+DQo+IElmIHRo
YXQgaXMgbm90IGFuIG9wdGlvbiwgd2Ugd291bGQvY291bGQgbmVlZCBtZWFucyB0byBpZGVudGlm
eSB0aGUgDQo+IHR5cGUgb2YgcGFyYW1ldGVycyBpbiBhIGZvcmV3YXJkIGNvbXBhdGlibGUgd2F5
LiBJLmUuLCBjb252ZW50aW9ucyBieSB3aGljaCB3ZSB3b3VsZCBpZGVudGlmeSBpbiB0aGUgZnV0
dXJlIHBhcmFtZXRlcnMgYSByZWNlaXZlciBjYW4gc2FmZWx5IGlnbm9yZSBhbmQgYXR0ZW1wdCB0
byBkZWNvZGUsIGFuZCBwYXJhbWV0ZXJzIGEgcmVjZWl2ZXIgY2Fubm90IHNhZmVseSBpZ25vcmUu
DQoNCkkgdGhpbmsgaXQgaXMgZmluZSB0byBzYXkgdGhhdCB1bnJlY29nbml6ZWQgcGFyYW1ldGVy
cyBzaGFsbCBiZSBpZ25vcmVkLiBJdCBpcyB0aGVuIHVwIHRvIGZ1dHVyZSBzcGVjaWZpY2F0aW9u
cyB0byB3b3JyeSBhYm91dCBiYWNrd2FyZCBjb21wYXRpYmlsaXR5LCByYXRoZXIgdGhhbiB0aGlz
IHNwZWNpZmljYXRpb24gd29ycnlpbmcgYWJvdXQgZm9yd2FyZCBjb21wYXRpYmlsaXR5Lg0KDQo+
PiBBbHNvLCB0aGUgdGV4dCBkb2VzIG5vdCBzYXkgd2hhdCByZXN0cmljdGlvbnMgKGlmIGFueSkg
dGhlcmUgYXJlIHdoZW4gDQo+PiBpdCBjb21lcyB0byBtb2RpZnkgdGhlIHN0cmVhbSBkdXJpbmcg
YSBzZXNzaW9uLiBJcyBpdCBhbGxvd2VkIHRvIA0KPj4gbW9kaWZ5IGFueS9hbGwgY2hhcmFjdGVy
aXN0aWNzPw0KPg0KPiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgeW91IGNhbm5vdCBtb2RpZnkg
Y2hhcmFjdGVyaXN0aWNzIGR1cmluZyBhIA0KPiBzZXNzaW9uLiBJZiB5b3UgbmVlZCB0byBtb2Rp
ZnksIHlvdSBuZWVkIHRvIHNldHVwIGEgbmV3IHNlc3Npb24gYW5kIA0KPiBjYW5jZWwgdGhlIGN1
cnJlbnQgb25lLiBGb3IgSlBFRyBYUyBzdHJlYW0gZGVjb2RlcnMsIG9uZSBjYW5ub3QgZXhwZWN0
IHRoYXQgYW4gaW5zdGFuY2lhdGVkIGRlY29kZXIgY2FuIGRlY29kZSBmcm9tIG1vZGlmaWVkIHBh
cmFtZXRlcnMgaW4gbWlkLXN0cmVhbSBsZXZlbC4gVGhhdCBpcywgaWYgeW91IHN0YXJ0IGRlY29k
aW5nIGluIGZ1bGwtSEQsIGFuZCB0aGVuIHN0cmVhbSBwYXJhbWV0ZXJzIGJlY29tZSA4SywgdGhl
IGRlY29kZXIgd2lsbCBoYXZlIHRvIGFib3J0Lg0KDQpUaGVzZSBraW5kIG9mIHRoaW5ncyBuZWVk
IHRvIGJlIHNwZWNpZmllZC4gSSBkb24ndCB0aGluayBpdCBuZWVkcyB0byBiZSBmb3JiaWRkZW4g
dG8gdHJ5IHRvIG1vZGlmeSBzb21ldGhpbmcsIGJlY2F1c2UgdGhlcmUgY291bGQgYmUgdGV4dCB0
aGF0IHN0cm9uZ2x5IHJlY29tbWVuZHMgYWdhaW5zdCBkb2luZyBpdC4NCg0KUmVnYXJkcywNCg0K
Q2hyaXN0ZXINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCkF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQphdnRAaWV0Zi5vcmcN
Cmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3
LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fYXZ0JmQ9RHdJQ0FnJmM9ZXVHWnN0Y2FURGxsdmlt
RU44YjdqWHJ3cU9mLXY1QV9DZHBnblZmaWlNTSZyPUxUeFVHdWtMQ0VmRVVkb19icTA0OFEmbT1M
dGVmUWlMaGRyWHdVeWNhaDdabXNheWtfZHRIRi1oTUVCd0hvNkRwZXQwJnM9MXZaVHVGakktUWJl
eFA1b1g5cGdhMzVkWlp6dGhYR2duN1M4WmdvZDlMRSZlPQ0KDQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUg
TWFpbnRlbmFuY2UNCmF2dEBpZXRmLm9yZw0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu
Y29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19hdnQm
ZD1Ed0lDQWcmYz1ldUdac3RjYVREbGx2aW1FTjhiN2pYcndxT2YtdjVBX0NkcGduVmZpaU1NJnI9
TFR4VUd1a0xDRWZFVWRvX2JxMDQ4USZtPUx0ZWZRaUxoZHJYd1V5Y2FoN1ptc2F5a19kdEhGLWhN
RUJ3SG82RHBldDAmcz0xdlpUdUZqSS1RYmV4UDVvWDlwZ2EzNWRaWnp0aFhHZ243UzhaZ29kOUxF
JmU9DQo=


From nobody Sun May 30 23:44:18 2021
Return-Path: 
X-Original-To: avt@ietf.org
Delivered-To: avt@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 197203A2174; Sun, 30 May 2021 23:44:16 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= 
To: "The IESG" 
Cc: draft-ietf-payload-vp9@ietf.org, avtcore-chairs@ietf.org, avt@ietf.org, bernard.aboba@gmail.com, bernard.aboba@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.30.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= 
Message-ID: <162244345607.546.10845649528608602640@ietfa.amsl.com>
Date: Sun, 30 May 2021 23:44:16 -0700
Archived-At: 
Subject: [AVTCORE] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-payload-vp9-13=3A_=28with_COMMENT=29?=
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 May 2021 06:44:16 -0000

Éric Vyncke has entered the following ballot position for
draft-ietf-payload-vp9-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-payload-vp9/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document.

I have only one minor comment about section 4.1: please expand "VP9 pyld hdr" somewhere in the text.

-éric




From nobody Mon May 31 00:07:38 2021
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713663A2233 for ; Mon, 31 May 2021 00:07:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=intopix.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQpt_zaQLCaT for ; Mon, 31 May 2021 00:07:32 -0700 (PDT)
Received: from dispatchb-eu1.ppe-hosted.com (dispatchb-eu1.ppe-hosted.com [185.183.29.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA9203A222F for ; Mon, 31 May 2021 00:07:31 -0700 (PDT)
X-Virus-Scanned: Proofpoint Essentials engine
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05lp2112.outbound.protection.outlook.com [104.47.18.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1-eu1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 2790C6C0076; Mon, 31 May 2021 07:07:28 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QigZowFZI3AflM16OAHnrqRVnkR9exFPM6CJ5/Y1+HHvuoBRL1LbqFrKG/lzYN5dWNgy63GhvnKb3TKu26a2Bksh+/uC4y0T41jLDfwOQVgJIV9a5GOKoTLhJy07iM+S5sQpx3CUqNy1sMk20NcEWjdFok9JJL5sfQh7jdOPuEbVttRe0vT96Vjv9y7YUKoGNsPTJgk+tt9rSOOsGOlPA3ji2x3WoyY79LOLsFei1cfWlJZswtF8A9VnsNc3J87eOtXK7Mw7XbIHzDru7Wud2B6xkBfIR/K6ryvP8iiTMm2LA3WHEKEtZBxoPiOhEfK1c9oreqk6CR6xJTmBAHo7/A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5Ma2vBjg6qxYhO4SLwdAMcJWUeWqEDLvFlfuTKEQpNY=; b=K4qu9ydE3JChZ+U1I6xRQkPC7coooi+A+D89y0cCADed+uhgttx3adJafDLRFqng/YdEQgiY2a/Lim/o+GVZ/DOGbqSqJqIY7FlNKJmk28rtqGOny68AHw5gmCABxIwE89SisiOKnFsM9UbELBVoooW20ybUireEchxd8L9q6rXVNVcV8O71mQN2nYHKm8kzVrDR/CwMQiPsoExanYD2rTJyUEHLu1Y1oOuaKUMjcLFL2DQDLLrl5bYY4rMeYqTIQLJvBh7GJqKlUMxaR69ZM/IDj+Bp3Ax1CyqW3jSihI20tZy2tFmVMLC9WMwmmYQ7+lTT4EUlpTQBvTsAwzJIxA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intopix.com; dmarc=pass action=none header.from=intopix.com; dkim=pass header.d=intopix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intopix.onmicrosoft.com; s=selector1-intopix-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5Ma2vBjg6qxYhO4SLwdAMcJWUeWqEDLvFlfuTKEQpNY=; b=TTs45+kum2srIQNmxqjMYiehPQbqzKaUwSsko3/+LZFrhepAp3AFCfx1AQ7P0yzu5E2EO55pOCoaC5yIXka4jBLxLUT8voAmmlo1C80loXMkVcIKVOh6PiFvxtpeXXOnWdeY5/fhxcPI7S5G3qVpBAVVbyKBq+oXehFTZBne9DM=
Received: from PR3P192MB0748.EURP192.PROD.OUTLOOK.COM (2603:10a6:102:4f::24) by PAXP192MB1229.EURP192.PROD.OUTLOOK.COM (2603:10a6:102:19b::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.22; Mon, 31 May 2021 07:07:26 +0000
Received: from PR3P192MB0748.EURP192.PROD.OUTLOOK.COM ([fe80::8ab:c06a:c2cf:b0ac]) by PR3P192MB0748.EURP192.PROD.OUTLOOK.COM ([fe80::8ab:c06a:c2cf:b0ac%9]) with mapi id 15.20.4173.030; Mon, 31 May 2021 07:07:26 +0000
From: Tim Bruylants 
To: Tim Bruylants , Christer Holmberg , Thomas Richter , "avt@ietf.org" 
CC: Jean-Baptiste Lorent 
Thread-Topic: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
Thread-Index: AddLKBOH9HzaEV4jTtmQ8TPYzmKsqwFVwo+gABfRKwAAFpWSgABEymJQAABwR+AAT0NxwAAES3xQAAEQhVAAkqc4oA==
Date: Mon, 31 May 2021 07:07:26 +0000
Message-ID: 
References:    <7aa5e890-47c5-cdb7-5657-26864cec3d4c@iis.fraunhofer.de>     
In-Reply-To: 
Accept-Language: en-US, nl-NL
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: intopix.com; dkim=none (message not signed) header.d=none;intopix.com; dmarc=none action=none header.from=intopix.com;
x-originating-ip: [94.227.86.241]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 04ae8138-e315-4321-bf76-08d92402bf5c
x-ms-traffictypediagnostic: PAXP192MB1229:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: tE31razrJqFEPE/4mxv1U0+EB6HgDC+Vj2K8Cj7VI+AUdqwGVyzEvCBSWZdpS70OJ8Bt3Wwif1iI1+t1K5yG2MZE7RLG2EoD9OoNjftF6aZ/vtz1lQXj5yYHxX/xoD3DtSa+5WTvkg32fL940eCNI46JilmNHSgf4xW9ysWx6Q4MtuexMN2/f9Zx+rn+wEHszwDYuMzANy1O7odStIptaDkExw0SDlcquzw5uu4arJTBqaPidbnUhH2dRUW7LAoZbTpt3Ofeo8wlxJRmtlpAi0zqWGVtx7tblGPvQR07RaDCvdiHBfaEzVXC3XLiNsXS4hDDYDaAyAl8ufu2HOZeZeFAVPmnhR4AvNJm0PkuZqxVwS1I1YWuzQwGY/GkOtKKDlUT6kzD+CHdLrW+8dGh5h6d6L8iIZ99A0FXDv69eKItc27xCoKxpK0NNss7L+rQggeZPkAzfHJSwqFgy6E57OYr2LL55169phzTEmf2brTMUVnlvr2Mqq0/4UHPM8TlGnX3K4NlPtPrWsHUxWnnhrRGhH/dEv7Y9uwpTzGkjC4J7RJQkanCguwnEN0tDNsE4np5bL+efCkCyb8ogLWnCYqjaPKSbmE1oaYv1zA+CiN7jLO4lS+TV9OQQ7NPfX49zdycmv3iiVHTa1f4Hcto0uO866vTCUyPn4Af/eY7S2f7qksx5bCTLIlEUWVNNtBtLQ4dCT96xHTeyIwpZGfDVjmNxgwJ/Dpo55bEAHwwrRs=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:PR3P192MB0748.EURP192.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFS:(39830400003)(396003)(366004)(136003)(346002)(376002)(478600001)(52536014)(66446008)(83380400001)(110136005)(5660300002)(9686003)(316002)(7696005)(2906002)(4326008)(64756008)(66476007)(66556008)(76116006)(38100700002)(186003)(966005)(8936002)(8676002)(26005)(6506007)(33656002)(53546011)(66946007)(30864003)(55016002)(122000001)(86362001)(107886003)(71200400001); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?utf-8?B?b1UxUDBUelJrR0tXN285WUEzZVlRelhGWXJLWVJyWFhoOFdJMU43NWw5c1Uv?= =?utf-8?B?RU5HMUNGank4ZjgrVnhRbVg5aVlKTE9CMVhCR0hzeUkxM0E4R05qODlOT0pv?= =?utf-8?B?algrVWdHRHg1ZEF3M005RWVPZHZ5UmhSZ0NYTTN1OTRZSnZ4dXRqRGMxM09Z?= =?utf-8?B?WldPL2g5RVhGdW9pSFU3T24vc1B5Ry84QU1ZcHg1MXhFbTdTQk5hVW00aWNE?= =?utf-8?B?WjNDMXlzeXhhNDZWT1dyZ3J4Wk9aeTc5WnVITmVDR01lbU42ZnVWSTJlSXlP?= =?utf-8?B?T2xiQ1F3OENDUWNLOXAwM1htT2pvdVNCb0ZtVlJkWHY3ck80ZUpwQzU3R1ht?= =?utf-8?B?ZDFqSjBxM2x6U0pNUlh0Y21jSjZ1bVV2Z3RPTGdwUnNqS1g5c01RclFEODFI?= =?utf-8?B?b3diRkVEWTZieWJmWHJlNUdEZXhKNFFJVS96dTc3Q1Q2cHAxVlMxeDRxY0hQ?= =?utf-8?B?WDlGT3pXOFExTmJvLzFCZC8rRzg3RkFYL2FLaGxFQ0luRGgxV09OUGQ3UTAx?= =?utf-8?B?WTV1aXlmZXlHVS80cTBuTUdUUGM5MlRXQVJVWWNYKzFGZnVGMnY4WnZBdVM2?= =?utf-8?B?azUzNjF2SDRrejdSOEh3NHpCS0w2WWJWeHJVaGMrOUowYlMvaHNoaGVWR1U2?= =?utf-8?B?MzNxNTd0SkxYRk1BWmVWUk05bFAvTGovWkQ2TDA0MjlIbDl0cTdVWExvWU40?= =?utf-8?B?M3BKeUFURlpWL1ArRGx0VWNVYkJXaDVCTHZnYUgyRzRQY1JMNUhwTzN6cUo2?= =?utf-8?B?QnczNzZuY3lkOVNFdWFMWFNDNHZBU3hnMWhzWHVhVm5QSWlPOEduUzJOY29W?= =?utf-8?B?cEhoWEh2ZlNOVVhBZFdjenF0SmtPSUZDQlRncFRFOWJJWlQ4SkcyZEJzNGQ1?= =?utf-8?B?d0NwaDN1cFBVeVA5eFdqY3ByNUQ5V2N0MEYrd3NnbTQ4NVFQMnBjWFYrY0dm?= =?utf-8?B?UE42M2NLaE1QZ3NLYTlpaGxVZGVoeUgxMkU5OUNkSitNdkFSaXJLZ2w2cEZ2?= =?utf-8?B?T0RHTUhHeStLem54MUh4dTlNc05rUEpLNXhwZ0JuUk1CZFhaZVNjb3ZuYTYr?= =?utf-8?B?YTN1VWF4eDM1V0VqQldYYlJUVWZwcXowekdwUzNzN3BwUTA2K05pV1NFTVRC?= =?utf-8?B?WjlsLysrZGMxZE5CRHU5OFBpT0plaWcrZ0hlSkdRbXlFRzFrQks4ZlhXOWJD?= =?utf-8?B?OGNyamxxVDlVWWxtcml6MVA3enBkbUJ0ajZCNWRLK29UVGU4bHRBbWFqemhw?= =?utf-8?B?V2tLTVhaM1RIYUFyOWZ0OWpWaVlIc3NQZ0tmZVBZemJ1TjlnNys1ZGdZRTN1?= =?utf-8?B?bmRWYXhNMjFTZnZodk9WMnplVDdnMnMxYkM3UTc5eFRWOUxqeVc5MDkyYUFT?= =?utf-8?B?eU9SYWlTOXVVT0orczl1TytJK0pxblEzYUJockhweHltRFgrcStxbjkrZFZh?= =?utf-8?B?bks0NnZoN1RlbmsrN2ZCblRNTlpLaVBlY3RzWWs0Y1BXSGI2TUR5SFJBanlm?= =?utf-8?B?bjAzVmxKWjh4V0JUK3ZlK1dXbE4xdHkxMXZPaUgvdDhSMkRHOWFnbWMxY1pr?= =?utf-8?B?SU9KUENtdVdscWs1dEEzQmpBbWZPdkZnTUdaUlFWVk90OWJOSVJ2VVZlRnlO?= =?utf-8?B?K0tHVDRuN3A5OEkvcGNiSXBsZjhhekU5RGM1ZlNnd3FYVVBrQ0cwUVpMV1Q3?= =?utf-8?B?bEtXU3EvcGVXaXFlUStHWVBYb0VOci8vQUxwTThDUTFhVGZCQlM2ZHJSc1JQ?= =?utf-8?Q?iXxjeBCiUoKavkjJA4uXpYeWFDpTZqWWF9tnP9D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: intopix.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PR3P192MB0748.EURP192.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 04ae8138-e315-4321-bf76-08d92402bf5c
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2021 07:07:26.7542 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5f9168c7-cdac-4b23-9509-c278399e3c1f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: S+EYj1X5jt3Yl+r5QnUVZvCSsjwdmTtlF4tPDe9F6Y6R17UitjSrf7DsrVG3PWrR
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXP192MB1229
X-MDID: 1622444849-qr6PplDDoHAF
Archived-At: 
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 May 2021 07:07:38 -0000

SGkgQ2hyaXN0ZXIsDQoNCkJlZm9yZSBJIHVwbG9hZCBhIG5ldyBkcmFmdCB0byBhZGRyZXNzIHRo
ZSBTRFAsIEkgd291bGQgbGlrZSB5b3UgdG8gcmV2aXNlIHRoZSBmb2xsb3dpbmcgdGV4dC4NCg0K
QXMgeW91IHN0YXRlZCwgd2hlbiBkZXNjcmliaW5nIHRoZSBTRFAgb2ZmZXIvYW5zd2VyIG1vZGVs
LCB0aGUgZHJhZnQgbmVlZHMgdG8gYWRkcmVzcyB0aGUgNSBmb2xsb3dpbmcgdG9waWNzOg0KWC4x
IEdlbmVyaWMgU0RQIENvbnNpZGVyYXRpb25zDQpYLjIuICBHZW5lcmF0aW5nIHRoZSBJbml0aWFs
IFNEUCBPZmZlcg0KWC4zLiAgR2VuZXJhdGluZyB0aGUgU0RQIEFuc3dlcg0KWC40LiAgT2ZmZXJl
ciBQcm9jZXNzaW5nIG9mIHRoZSBTRFAgQW5zd2VyDQpYLjUuICBNb2RpZnlpbmcgdGhlIFNlc3Np
b24NCg0KT3VyIHF1ZXN0aW9uOiBJcyB0aGlzIHN1ZmZpY2llbnRseSBkZXNjcmliZWQgaW4gUkZD
MzI2NCBhbmQgaXMgaXQgb2sgdG8gcmVmZXIgdG8gdGhhdCBSRkMgd2l0aCBzb21lIGV4dHJhIGNs
YXJpZmljYXRpb25zPyBSRkMzMjY0IHNlZW1zIHRvIGJlIHdoYXQgd2UgaW50ZW5kICJpZiIgc2Rw
IG9mZmVyL2Fuc3dlciBpcyB1c2VkLiBUaGlzIHdvdWxkIHJlc3VsdCBpbiB0aGUgZm9sbG93aW5n
IHRleHQ6DQoNCi8vLS0tIFNOSVBQRVQNCjguMi4gIFVzYWdlIHdpdGggU0RQIE9mZmVyL0Fuc3dl
ciBNb2RlbA0KDQogICBXaGVuIEpQRUcgWFMgaXMgb2ZmZXJlZCBvdmVyIFJUUCB1c2luZyBTRFAg
aW4gYW4gb2ZmZXIvYW5zd2VyIG1vZGVsDQogICBbUkZDMzI2NF0gZm9yIG5lZ290aWF0aW9uIGZv
ciB1bmljYXN0IHVzYWdlLCB0aGUgZm9sbG93aW5nDQogICBsaW1pdGF0aW9ucyBhbmQgcnVsZXMg
YXBwbHk6DQoNCiAgICAgIFRoZSAiYT1mbXRwIiBhdHRyaWJ1dGUgU0hBTEwgYmUgcHJlc2VudCBz
cGVjaWZ5aW5nIHRoZSByZXF1aXJlZA0KICAgICAgcGFyYW1ldGVyICJ0cmFuc21vZGUiIGFuZCBN
QVkgc3BlY2lmeSBhbnkgb2YgdGhlDQogICAgICBvcHRpb25hbCBwYXJhbWV0ZXJzLCBhcyBkZXNj
cmliZWQgaW4gU2VjdGlvbiA3LjEuDQoNCiAgICAgIEFsbCBwYXlsb2FkIHBhcmFtZXRlcnMgYXJl
IGRlY2xhcmF0aXZlLCBtZWFuaW5nIHRoYXQgdGhleSBkZXNjcmliZQ0KICAgICAgcHJvcGVydGll
cyBvZiB0aGUgcGF5bG9hZC4NCg0KICAgICAgQSByZWNlaXZlciBvZiB0aGUgU0RQIGlzIHJlcXVp
cmVkIHRvIHN1cHBvcnQgYWxsIHBhcmFtZXRlcnMgYW5kDQogICAgICB2YWx1ZXMgb2YgdGhlIHBh
cmFtZXRlcnMgcHJvdmlkZWQ7IG90aGVyd2lzZSwgdGhlIHJlY2VpdmVyIFNIQUxMDQogICAgICBy
ZWplY3QgdGhlIHNlc3Npb24uICBJdCBmYWxscyBvbiB0aGUgY3JlYXRvciBvZiB0aGUgc2Vzc2lv
biB0byB1c2UNCiAgICAgIHZhbHVlcyB0aGF0IGFyZSBleHBlY3RlZCB0byBiZSBzdXBwb3J0ZWQg
YnkgdGhlIHJlY2VpdmluZw0KICAgICAgYXBwbGljYXRpb24uDQovLy0tLSBTTklQUEVUDQoNCkZl
ZWRiYWNrIHdvdWxkIGJlIHZlcnkgd2VsY29tZS4NCg0KS2luZCByZWdhcmRzLA0KVGltLg0KDQoN
Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBhdnQgPGF2dC1ib3VuY2VzQGlldGYu
b3JnPiBPbiBCZWhhbGYgT2YgVGltIEJydXlsYW50cw0KU2VudDogRnJpZGF5IDI4IE1heSAyMDIx
IDEyOjIxDQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u
LmNvbT47IFRob21hcyBSaWNodGVyIDx0aG9tYXMucmljaHRlckBpaXMuZnJhdW5ob2Zlci5kZT47
IGF2dEBpZXRmLm9yZw0KQ2M6IEplYW4tQmFwdGlzdGUgTG9yZW50IDxqYi5sb3JlbnRAaW50b3Bp
eC5jb20+DQpTdWJqZWN0OiBSZTogW0FWVENPUkVdIFNEUCBkaXJlY3RvcmF0ZSByZXZpZXcgb2Yg
ZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1qcGVneHMtMTMNCg0KSGkgQ2hyaXN0ZXIsDQoNClRoYW5r
cyBmb3IgdGhlIHF1aWNrIHJlc3BvbnNlLCB3ZSByZWFsbHkgYXBwcmVjaWF0ZSB5b3VyIHRpbWUu
DQoNClNvLCBsZXQgbWUgZWxhYm9yYXRlIGEgYml0Og0KDQo+PiBGaXJzdCwgcmVnYXJkaW5nIFJG
QyA4NDUwLCB0aGF0IHNwZWNpZmljYXRpb24gd2FzIHByb2JhYmx5IG5ldmVyIHJldmlld2VkIGJ5
IHRoZSBTRFAgZGlyZWN0b3JhdGUsIHNvIEkgY2FuJ3QgcmVhbGx5IGNvbW1lbnQgb24gdGhhdC4g
QnV0LCBJIHNlZSB0aGF0IHRoZSBSRkMgZS5nLiwgc2F5cyBub3RoaW5nIGFib3V0IHdoZXRoZXIg
dGhlIFNEUCBpbmRpY2F0ZXMgc2VuZGluZyBvciByZWNlaXZpbmcgY2FwYWJpbGl0aWVzLg0KDQpP
aywgSSB1bmRlcnN0YW5kIHRoYXQgUkZDIDg0NTAgbWlnaHQgbm90IGJlIGVudGlyZWx5IGNsZWFy
IG9yIHdlbGwgd3JpdHRlbiBvbiB0aGUgU0RQIHBhcnQuDQoNCj4+IFNlY29uZCwgbm9ib2R5IG1h
bmRhdGVzIHlvdSB0byB1c2UgU0RQLCBhbmQgbW9zdCBwYXJ0IG9mIHRoZSBzcGVjIGlzIHByb3Rv
Y29sIGluZGVwZW5kZW50LiBCdXQsIHRoZSAiU0RQIE9mZmVyL0Fuc3dlciIgc2VjdGlvbiBkZXNj
cmliZXMgdGhlIFNEUCBvZmZlci9hbnN3ZXIgcHJvY2VkdXJlcywgKklGKiB5b3UgY2hvb3NlIHRv
IHVzZSB0aGF0IG1lY2hhbmlzbSBmb3IgbmVnb3RpYXRpbmcgdGhlIHNlc3Npb24uDQoNCk9rLiBU
aGF0IEkgdW5kZXJzdGFuZC4gSW4gb3VyIGNhc2UsIFNEUCBhcyB0aGUgc2Vzc2lvbiBwcm90b2Nv
bCBpcyBub3QgY3JpdGljYWwsIGJ1dCBzdGlsbCBhIG5pY2UgdG8gaGF2ZS4gRG8geW91IGFncmVl
PyBPciBkbyB5b3UgcmVjb21tZW5kIHdlIHJlbW92ZSB0aGUgU0RQIG9mZmVyL2Fuc3dlciBzZWN0
aW9uPw0KDQpXaGF0IHdlIGRvIG5lZWQgdG8gc2F5IGlzIGhvdyB0byBtYXAgcGFyYW1ldGVycyBp
bnRvIGFuIFNEUC1jb21wbGlhbnQgZm9ybWF0IGRlc2NyaXB0aW9uLCBmb3IgdGhlIHNhbWUgcmVh
c29ucyBhcyBSRkMgODQ1MCBhbmQgbWFueSBvdGhlciB2aWRlbyBwYXlsb2FkIFJGQydzIChWUDgs
IFZQOSwgSC4yNjQvQVZDLCBILjI2NS9IRVZDLCBldGMpLiBUaGlzIGFsbG93cyB1c2luZyBtYW55
IG90aGVyIHNlc3Npb24gbmVnb3RpYXRpb24gcHJvdG9jb2xzIHRoYXQgcmVseSBvbiB0aGUgU0RQ
IGRlc2NyaXB0aW9uLg0KDQo+PiBUaGlyZCAuLi4uDQoNCkkgYmVsaWV2ZSB3aGF0IGlzIHZlcnkg
aW1wb3J0YW50IHRvIGV4cGxhaW4gaXMgdGhhdCBhbGwgb2Ygb3VyIHBhcmFtZXRlcnMgYXJlIGRl
Y2xhcmF0aXZlLCBtZWFuaW5nIHRoYXQgdGhleSBkZXNjcmliZSBleGFjdCBiaXRzdHJlYW0gcHJv
cGVydGllcywgYW5kIG5vdCByZWNlaXZlciBjYXBhYmlsaXRpZXMuIFRoZSBTRFAgcGFyYW1ldGVy
cyBjYW4gYmUgdXNlZCB0byBjb21tdW5pY2F0ZSBiZXR3ZWVuIHNlbmRlci9yZWNlaXZlciB3aGF0
IHRoZXkgd2lzaCB0byBleGNoYW5nZSBiZWZvcmUgc2VuZGluZyBhY3R1YWwgcGF5bG9hZCwgYnV0
IG5vbmUgb2YgdGhlc2UgcGFyYW1ldGVycyBvciB2YWx1ZXMgYXJlICJkb3duZ3JhZGFibGUiIG9y
ICJpbmNsdXNpdmUgY2FwYWJpbGl0eSBzZXRzIi4gWFMgZG9lcyBub3QgaGF2ZSBzdWNoIGNvbmNl
cHRzLCBhcyBpdCBpcyBhIGxvdy1jb21wbGV4aXR5IGNvZGVjLCBpbnRlbmRlZCBwcmltYXJpbHkg
dG8gcmVwbGFjZSB1bmNvbXByZXNzZWQgdmlkZW8gc3RyZWFtcy4NCg0KU29tZWhvdywgdGhpcyBy
YWlzZXMgdGhlIGZvbGxvd2luZzoNCg0KWC4xIEdlbmVyaWMgU0RQIENvbnNpZGVyYXRpb25zDQog
IEkgYmVsaWV2ZSBoZXJlIHdlIGV4cGxhaW4gdGhhdCBwYXJhbWV0ZXJzIGFyZSBkZWNsYXJhdGl2
ZSBhbmQgcmVwcmVzZW50IGJpdHN0cmVhbS9wYXlsb2FkIHZhbHVlcy9zZXR0aW5ncy4gU28gYm90
aCBzaWRlcyBjYW4gdXNlIHRoZXNlIHRvIGluZGljYXRlIHdoYXQgdGhlIHBheWxvYWQgd2lsbCBs
b29rIGxpa2UuDQoNClguMi4gIEdlbmVyYXRpbmcgdGhlIEluaXRpYWwgU0RQIE9mZmVyDQogIE5v
dCBtdWNoIHRvIHNheSBoZXJlLiBBcyBJIHVuZGVyc3RhbmQgYW4gU0RQIHNlc3Npb24gY2FuIGJl
IGluaXRpYXRlZCBmcm9tIGVpdGhlciByZWNlaXZlciBvciBzZW5kZXIgc2lkZXM/IFNvLCB0aGV5
IGp1c3Qgc2VuZCBhIHZhbGlkIG1lZGlhIGRlc2NyaXB0aW9uIG9mIHRoZSBjb250ZW50IHRoZXkg
d2FudCB0byBleGNoYW5nZS4gSWYgZWl0aGVyIHNpZGUgY2Fubm90IGhhbmRsZSBjZXJ0YWluIHBh
eWxvYWQgc2V0dGluZ3MsIHRoZW4gaXQgc2hvdWxkIHJlamVjdCB0aGUgb2ZmZXIgKG9yIGFuc3dl
cikuIEFuIG9mZmVyZXIganVzdCBzZW5kcyB3aGF0IGl0IHdhbnRzIHRvIHJlY2VpdmUgb3Igc2Vu
ZC4NCg0KWC4zLiAgR2VuZXJhdGluZyB0aGUgU0RQIEFuc3dlcg0KICBJIGRvbid0IHRoaW5rIHRo
ZXJlIGlzIGFueXRoaW5nIHNwZWNpYWwgdG8gbWVudGlvbiBoZXJlPyBUaGUgYW5zd2VyZXIgdGFr
ZXMgdGhlIGRlY2xhcmF0aXZlIHBhcmFtZXRlcnMgYW5kIGVpdGhlciBhY2NlcHRzIG9yIHJlamVj
dHMgdGhlIHNlc3Npb24uIEl0IHNob3VsZCBOT1QgbW9kaWZ5IHRoZSBvZmZlciBpbiBhbnkgd2F5
Lg0KDQpYLjQuICBPZmZlcmVyIFByb2Nlc3Npbmcgb2YgdGhlIFNEUCBBbnN3ZXINCiAgSSBkb24n
dCB0aGluayB0aGVyZSBpcyBhbnl0aGluZyBzcGVjaWFsIHRvIG1lbnRpb24gaGVyZT8gSWYgdGhl
IGFuc3dlciBhY2NlcHRlZCB0aGUgb2ZmZXIsIHRoZW4gdGhlIHN0cmVhbSBjYW4gc3RhcnQuDQoN
ClguNS4gIE1vZGlmeWluZyB0aGUgU2Vzc2lvbg0KICBNb2RpZnlpbmcgdGhlIHNlc3Npb24gaXMg
cG9zc2libGUsIGJ1dCB0aGlzIGlzIHZlcnkgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMuIEJhc2lj
YWxseSwgbW9kaWZ5aW5nIGEgc2Vzc2lvbiBpcyB2ZXJ5IHNpbWlsYXIgdG8gY3JlYXRpb24gb2Yg
YSBuZXcgc2Vzc2lvbi4gQm90aCBzaWRlcyBzaG91bGQgYWdyZWUgb24gdGhlIHBheWxvYWQgdGhl
eSB3aWxsIGV4Y2hhbmdlLg0KDQoNCkknbSBzb3JyeSB0byBkcmFnIHRoaXMgb3V0LCBidXQgSSB0
aGluayB0aGF0IGhhdmluZyB0aGlzIGNvbnZlcnNhdGlvbiBieSBlbWFpbCBpcyBtb3JlIGVmZmlj
aWVudCB0aGFuIHBvc3RpbmcgZHJhZnRzIPCfmIogSSBhcHByZWNpYXRlIHlvdXIgZmVlZGJhY2su
DQoNClRpbS4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQ2hyaXN0ZXIg
SG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NClNlbnQ6IEZyaWRheSAy
OCBNYXkgMjAyMSAxMDozOQ0KVG86IFRpbSBCcnV5bGFudHMgPFRCUkBpbnRvcGl4LmNvbT47IFRo
b21hcyBSaWNodGVyIDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9
aHR0cC0zQV9fdGhvbWFzLnJpY2h0ZXItNDBpaXMuZnJhdW5ob2Zlci5kZSZkPUR3SUdhUSZjPWV1
R1pzdGNhVERsbHZpbUVOOGI3alhyd3FPZi12NUFfQ2RwZ25WZmlpTU0mcj1MVHhVR3VrTENFZkVV
ZG9fYnEwNDhRJm09VnZzYTd1RkE1ejBEV25CU29ORW52YV80aWo1cmJjUUdPd0xwX2ktM3o3dyZz
PWF1ZUppb1RsdFkwNWt4ZkIyMVJGT3ZTUXN6OGx1bFRveVhRemJjdEpDdmMmZT0+OyBhdnRAaWV0
Zi5vcmcNCkNjOiBKZWFuLUJhcHRpc3RlIExvcmVudCA8amIubG9yZW50QGludG9waXguY29tPg0K
U3ViamVjdDogUkU6IFtBVlRDT1JFXSBTRFAgZGlyZWN0b3JhdGUgcmV2aWV3IG9mIGRyYWZ0LWll
dGYtcGF5bG9hZC1ydHAtanBlZ3hzLTEzDQoNCkhpLA0KDQpGaXJzdCwgcmVnYXJkaW5nIFJGQyA4
NDUwLCB0aGF0IHNwZWNpZmljYXRpb24gd2FzIHByb2JhYmx5IG5ldmVyIHJldmlld2VkIGJ5IHRo
ZSBTRFAgZGlyZWN0b3JhdGUsIHNvIEkgY2FuJ3QgcmVhbGx5IGNvbW1lbnQgb24gdGhhdC4gQnV0
LCBJIHNlZSB0aGF0IHRoZSBSRkMgZS5nLiwgc2F5cyBub3RoaW5nIGFib3V0IHdoZXRoZXIgdGhl
IFNEUCBpbmRpY2F0ZXMgc2VuZGluZyBvciByZWNlaXZpbmcgY2FwYWJpbGl0aWVzLg0KDQpTZWNv
bmQsIG5vYm9keSBtYW5kYXRlcyB5b3UgdG8gdXNlIFNEUCwgYW5kIG1vc3QgcGFydCBvZiB0aGUg
c3BlYyBpcyBwcm90b2NvbCBpbmRlcGVuZGVudC4gQnV0LCB0aGUgIlNEUCBPZmZlci9BbnN3ZXIi
IHNlY3Rpb24gZGVzY3JpYmVzIHRoZSBTRFAgb2ZmZXIvYW5zd2VyIHByb2NlZHVyZXMsICpJRiog
eW91IGNob29zZSB0byB1c2UgdGhhdCBtZWNoYW5pc20gZm9yIG5lZ290aWF0aW5nIHRoZSBzZXNz
aW9uLg0KDQpUaGlyZCwgSSBkb24ndCB0aGluayB5b3UgbmVlZCB2ZXJ5IG11Y2ggdGV4dC4gVGhl
IGltcG9ydGFudCB0aGluZyBpcyB0byBzYXkgd2hhdCBpcyBwbGFjZWQgaW4gb2ZmZXJzIGFuZCBh
bnN3ZXJzLCB3aGV0aGVyIHRoZXJlIGFyZSBjb25zdHJhaW50cyB3aGVuIGdlbmVyYXRpbmcgdGhl
IGFuc3dlciwgYW5kIHdoZXRoZXIgdGhlcmUgYXJlIGNvbnN0cmFpbnRzIHdoZW4gaXQgY29tZXMg
dG8gbW9kaWZ5aW5nIHRoZSBzZXNzaW9uLiBBbmQsIHlvdSBkbyBOT1QgIG5lZWQgdG8gc3BlY2lm
eSBIT1cgdG8gbW9kaWZ5IGEgc2Vzc2lvbiwgYnV0IHdoZXRoZXIgdGhlcmUgYXJlIHBheWxvYWQt
c3BlY2lmaWMgY29uc3RyYWludHMgd2hlbiBkb2luZy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXIN
Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRpbSBCcnV5bGFudHMgPFRCUkBp
bnRvcGl4LmNvbT4NClNlbnQ6IHBlcmphbnRhaSAyOC4gdG91a29rdXV0YSAyMDIxIDkuNDkNClRv
OiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPjsgVGhv
bWFzIFJpY2h0ZXIgPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o
dHRwLTNBX190aG9tYXMucmljaHRlci00MGlpcy5mcmF1bmhvZmVyLmRlJmQ9RHdJRkFnJmM9ZXVH
WnN0Y2FURGxsdmltRU44YjdqWHJ3cU9mLXY1QV9DZHBnblZmaWlNTSZyPUxUeFVHdWtMQ0VmRVVk
b19icTA0OFEmbT1nZkI0UEYtdlZCVy1IVnhjU3hDeDA3TENoUTFDU2VwWU4zSm51dlBadmhnJnM9
V2cwOGkzMjEzYkN5UDBZYjhIajVpaHBCV2otZGxyVm5LRGRqZ2dPSmJxQSZlPT47IGF2dEBpZXRm
Lm9yZw0KQ2M6IEplYW4tQmFwdGlzdGUgTG9yZW50IDxqYi5sb3JlbnRAaW50b3BpeC5jb20+DQpT
dWJqZWN0OiBSRTogW0FWVENPUkVdIFNEUCBkaXJlY3RvcmF0ZSByZXZpZXcgb2YgZHJhZnQtaWV0
Zi1wYXlsb2FkLXJ0cC1qcGVneHMtMTMNCg0KSGkgQ2hyaXN0ZXIsDQoNCkknbSBhIGxpdHRsZSBi
aXQgc3R1Y2sgaW4gaG93IHRvIHJlc29sdmUgYW5kIGFkZHJlc3MgeW91ciBjb21tZW50cy4gT24g
b25lIGhhbmQgSSB1bmRlcnN0YW5kIHRoYXQgd2Ugd2FudCB0aGUgdGV4dCB0byBiZSBjbGVhciwg
YnV0IG9uIHRoZSBvdGhlciBoYW5kIHdlIGRvIG5vdCB3YW50IHRvIHJlcGVhdCBTRFAgc3BlY2lm
aWNzIHRvbyBtdWNoLiBTRFAgaXMganVzdCBvbmUgd2F5IHRvIG5lZ290aWF0ZSBhIHNlc3Npb24s
IGFuZCBpbiB0aGUgY2FzZSBvZiBYUyBpdCBpcyBub3QgdGhlIG1vc3QgY29tbW9ubHkgdXNlZCBv
bmUuIFhTIGlzIG5vdCByZWFsbHkgaW50ZW5kZWQgZm9yIHRoZSBjbGFzc2ljYWwgdmlkZW8tY2Fs
bCBjYXNlLCBidXQgcmF0aGVyIHRvIHN0cmVhbSBoaWdoLXF1YWxpdHkgdmlkZW8gY29udGVudCBp
biBhIHByb2Zlc3Npb25hbCBlbnZpcm9ubWVudC4gSXQgY2FuIGJlIHVzZWQgZm9yIHZpZGVvIGNv
bmZlcmVuY2luZywgYnV0IGJldHRlciBzdWl0ZWQgY29kZWNzIGV4aXN0IGZvciB0aGF0IHVzZS1j
YXNlLg0KDQpIb3dldmVyLCB3aGF0IGlzIGltcG9ydGFudCB0byBsYXkgb3V0IGNvcnJlY3RseSBp
cyB0aGUgbWFwcGluZyBvZiB0aGUgbWVkaWEgcGFyYW1ldGVycyBpbnRvIHRoZSBhPWZtdHAgZmll
bGQgb2YgU0RQLCBiZWNhdXNlIHRoaXMgaXMgYWN0dWFsbHkgdXNlZCBieSBtYW55IG90aGVyIHBy
b3RvY29scyAoc28sIGp1c3QgdGhlIG1lZGlhIGRlc2NyaXB0aW9uIHBhcnQgb2YgU0RQIGlzIHVz
ZWQpLg0KDQpPcmlnaW5hbGx5LCB3ZSBiYXNlZCBvdXIgZHJhZnQgdGV4dCBvbiBSRkMgODQ1MCAo
VkMtMiBIUSBSVFAgUGF5bG9hZCkuIEluIHRoYXQgcmVzcGVjdCwgd2hhdCBpcyB3cml0dGVuIHRo
ZXJlIGtpbmQgb2YgZml0cyBleGFjdGx5IHdoYXQgd2Ugd2FudCB3aXRoIFhTLiBHaXZlbiB0aGF0
IHRoaXMgaXMgYSBwdWJsaXNoZWQgUkZDLCB3ZSBhcmUgcHV6emVsZWQgYSBiaXQgYXMgdG8gd2h5
IG91ciBkcmFmdCB3b3VsZCBuZWVkIHRvIGVsYWJvcmF0ZSBzbyBleHRlbnNpdmVseSBvbiBTRFAu
IEZvciBzdXJlLCB3ZSdkIGxpa2UgdG8gYWxsb3cgU0RQIG9mZmVyL2Fuc3dlciBuZWdvdGlhdGlv
biB3aXRoIFhTLiBCdXQgdGhpcyBpcyB2ZXJ5IHNpbXBsZTogZWFjaCBzaWRlIHRlbGxzIHRoZSBv
dGhlciBzaWRlIHdoYXQgaXQgc3VwcG9ydHMsIGFuZCB0aGF0J3MgaXQuIEluIFhTIHRoZSBwYXJh
bWV0ZXJzIGFyZSBkZWNsYXJhdGl2ZSwgbWVhbmluZyAoYXQgbGVhc3QgdGhhdCdzIHdoYXQgd2Ug
d2FudCB0byBleHByZXNzKSB0aGF0IGVhY2ggcGFyYW1ldGVyIGlzIHJlcHJlc2VudHMgYW4gZXhh
Y3QgdmFsdWUgYW5kIGlzIG5vdCAiaW5jbHVzaXZlIiBpbnRvIGEgcmFuZ2Ugb2YgbGVzc2VyIHZh
bHVlcy4gSW4gb3RoZXIgd29yZHMsIHRoZSBvdGhlciBzaWRlIGNhbm5vdCBleHBlY3QgdGhhdCBh
ICJsZXNzZXIiIHZhbHVlIG9mIGEgcGFyYW1ldGVyIGNhbiB3b3JrLg0KDQpZb3VyIHByb3Bvc2Vk
IHN0cnVjdHVyZSBpcyBqdXN0IHRvIGVsYWJvcmF0ZSBhbmQgb3V0IG9mIHNjb3BlLiBBcyBzdWNo
LCBJIHdvdWxkIGFzayB5b3UgdG8gY29uc2lkZXIgdGhlIGV4YW1wbGUgb2YgUkZDIDg0NTAgKHdo
ZXJlIHRoZSB1c2UtY2FzZSBhbmQgcHVycG9zZSBtYXRjaGVzIHRoYXQgb2Ygb3VyIGRyYWZ0KS4g
Rm9yIGV4YW1wbGU6IFdoeSBkbyB3ZSBuZWVkIHRvIHN0YXRlIGFueXRoaW5nIHNwZWNpZmljIG9u
ICJNb2RpZnlpbmcgdGhlIFNlc3Npb24iPyBJc24ndCB0aGlzIGxheWVkIG91dCBieSBTRFAgb24g
aG93IHRvIG1vZGlmeSBhIHNlc3Npb24/IFRoZXJlJ3Mgbm90aGluZyBzcGVjaWZpYyB0byBiZSBw
dXQgaW4gb3VyIGRyYWZ0ICh3ZSBkbyBub3Qgd2FudCB0byBwcmV2ZW50LCBub3Qgc3VnZ2VzdCB0
aGlzIGZ1bmN0aW9uYWxpdHkpLg0KDQpJIGhvcGUgeW91IGNhbiB1bmRlcnN0YW5kIG91ciBkaWZm
aWN1bHR5IHdpdGggeW91ciByZW1hcmtzIGFuZCBjb21tZW50cy4gT3VyIHByb3Bvc2FsIGFzIHN1
Y2ggaXMgdG8ga2VlcCB0aGUgdGV4dCBhYm91dCBTRFAgdmVyeSBzaG9ydCBhbmQgc2ltcGxlLiBU
aGUgUlRQIFBheWxvYWQgZHJhZnQgY2FuIGJlIHVzZWQgd2l0aCBTRFAsIGJ1dCBpdCdzIGNlcnRh
aW5seSBub3QgdGhlIG9ubHkgd2F5Lg0KDQpJIHdpbGwgYmUgcHJlcGFyaW5nIGFuIHVwZGF0ZWQg
ZHJhZnQgd2hpY2ggdHJpZXMgdG8gYmUgdmVyeSBtaW5pbWFsIG9uIHRoZSBTRFAgc3BlY2lmaWNz
LiBVbmxlc3MgYW55dGhpbmcgaXMgdGVjaG5pY2FsbHkgd3JvbmcsIEkgcmVhbGx5IGhvcGUgeW91
IGNhbiBhZ3JlZSB0byBpdCBhbmQgbW92ZSBmb3J3YXJkIHdpdGggdGhlIHB1YmxpY2F0aW9uIHBy
b2Nlc3MuDQoNCkJlc3QgcmVnYXJkcywNClRpbS4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KRnJvbTogYXZ0IDxhdnQtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIENocmlz
dGVyIEhvbG1iZXJnDQpTZW50OiBXZWRuZXNkYXkgMjYgTWF5IDIwMjEgMTg6NDMNClRvOiBUaG9t
YXMgUmljaHRlciA8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0
dHAtM0FfX3Rob21hcy5yaWNodGVyLTQwaWlzLmZyYXVuaG9mZXIuZGUmZD1Ed0lGQWcmYz1ldUda
c3RjYVREbGx2aW1FTjhiN2pYcndxT2YtdjVBX0NkcGduVmZpaU1NJnI9TFR4VUd1a0xDRWZFVWRv
X2JxMDQ4USZtPWdmQjRQRi12VkJXLUhWeGNTeEN4MDdMQ2hRMUNTZXBZTjNKbnV2UFp2aGcmcz1X
ZzA4aTMyMTNiQ3lQMFliOEhqNWlocEJXai1kbHJWbktEZGpnZ09KYnFBJmU9PjsgYXZ0QGlldGYu
b3JnDQpTdWJqZWN0OiBSZTogW0FWVENPUkVdIFNEUCBkaXJlY3RvcmF0ZSByZXZpZXcgb2YgZHJh
ZnQtaWV0Zi1wYXlsb2FkLXJ0cC1qcGVneHMtMTMNCg0KVGhpcyBpcyBhIHN0cnVjdHVyZSB0aGF0
IGlzIHR5cGljYWxseSB1c2VkIGZvciBTRFAgb2ZmZXIvYW5zd2VyIHByb2NlZHVyZXM6DQoNClgu
ICBTRFAgT2ZmZXIvQW5zd2VyIFByb2NlZHVyZXMNCiAgICAgWC4xLiAgR2VuZXJpYyBTRFAgQ29u
c2lkZXJhdGlvbnMNCgk8SGVyZSB5b3UgY2FuIGRlc2NyaWJlIHRoaW5ncyB3aGljaCBhcHBseSB0
byBib3RoIG9mZmVycyBhbmQgYW5zd2Vycz4NCiAgICAgWC4yLiAgR2VuZXJhdGluZyB0aGUgSW5p
dGlhbCBTRFAgT2ZmZXINCgk8SGVyZSB5b3UgZGVzY3JpYmUgaG93IHRoZSBpbml0aWFsIFNEUCBv
ZmZlciBmb3IgdGhlIHNlc3Npb24gaXMgZ2VuZXJhdGVkPg0KICAgICBYLjMuICBHZW5lcmF0aW5n
IHRoZSBTRFAgQW5zd2VyDQoJPEhlcmUgeW91IGRlc2NyaWJlIGhvdyB0aGUgYW5zd2VyZXIgZ2Vu
ZXJhdGVzIHRoZSBTRFAgYW5zd2VyLCBpbmNsdWRpbmcgd2hldGhlciBwYXJhbWV0ZXJzL3BhcmFt
ZXRlciB2YWx1ZXMgbmVlZCB0byBiZSBhIHN1YnNldCBvZiB0aGUgcGFyYW1ldGVycy9wYXJhbWV0
ZXIgdmFsdWVzIGluIHRoZSBvZmZlciBldGM+DQogICAgIFguNC4gIE9mZmVyZXIgUHJvY2Vzc2lu
ZyBvZiB0aGUgU0RQIEFuc3dlcg0KICAgICA3LjUuICBNb2RpZnlpbmcgdGhlIFNlc3Npb24NCgk8
SGVyZSB5b3UgZGVzY3JpYmUgY29uc3RyYWludHMgcmVsYXRlZCB0byBtb2RpZmljYXRpb24gb2Yg
dGhlIHNlc3Npb24sIGluY2x1ZGluZyB3aGV0aGVyIHRoZXJlIGFyZSBjZXJ0YWluIHBhcmFtZXRl
cnMvcGFyYW1ldGVyIHZhbHVlcyB0aGF0IHlvdSBjYW5ub3QgbW9kaWZ5IGV0Yz4NCg0KUmVnYXJk
cywNCg0KQ2hyaXN0ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGF2dCA8
YXZ0LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBDaHJpc3RlciBIb2xtYmVyZw0KU2Vu
dDoga2Vza2l2aWlra28gMjYuIHRvdWtva3V1dGEgMjAyMSAxOS4zOA0KVG86IFRob21hcyBSaWNo
dGVyIDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9f
dGhvbWFzLnJpY2h0ZXItNDBpaXMuZnJhdW5ob2Zlci5kZSZkPUR3SUNBZyZjPWV1R1pzdGNhVERs
bHZpbUVOOGI3alhyd3FPZi12NUFfQ2RwZ25WZmlpTU0mcj1MVHhVR3VrTENFZkVVZG9fYnEwNDhR
Jm09THRlZlFpTGhkclh3VXljYWg3Wm1zYXlrX2R0SEYtaE1FQndIbzZEcGV0MCZzPS1UTzFRZjds
MV9xYzRrbFJLdmJ1VzhfZUQ0TDhmODVPQjVEYWhiMkxRR0UmZT0+OyBhdnRAaWV0Zi5vcmcNClN1
YmplY3Q6IFJlOiBbQVZUQ09SRV0gU0RQIGRpcmVjdG9yYXRlIHJldmlldyBvZiBkcmFmdC1pZXRm
LXBheWxvYWQtcnRwLWpwZWd4cy0xMw0KDQpIaSwNCg0KPj4gVW5mb3J0dW5hdGVseSBJIGRvbid0
IHRoaW5rIHdoYXQgeW91IGV4cGxhaW4gYWJvdmUgaXMgdmVyeSBjbGVhciBpbiANCj4+IHRoZSB0
ZXh0Lg0KPj4gDQo+PiBDb25zaWRlciB0aGUgZm9sbG93aW5nLg0KPj4gDQo+PiBUaGUgb2ZmZXJl
ciBzZW5kcyBhbiBvZmZlci4gVGhlIG9mZmVyZXIgc3BlY2lmaWVzIHRoZSBjaGFyYWN0ZXJpc3Rp
Y3MgDQo+PiB0aGF0IHRoZSBvZmZlcmVyIHdhbnRzIHRvIHJlY2VpdmUuIFNpbWlsYXJseSwgdGhl
IGFuc3dlciBzcGVjaWZpZXMgDQo+PiB0aGUgY2hhcmFjdGVyaXN0aWNzIHRoYXQgdGhlIGFuc3dl
cmVyIHdhbnRzIHRvIHJlY2VpdmUgLSB0aGUgYW5zd2VyZXIgDQo+PiBkb2VzIE5PVCBzcGVjaWZ5
IHdoYXQgaXQgaXMgZ29pbmcgdG8gc2VuZC4gd2hpY2ggSSB0aGluayB0aGUgdGV4dCBpcyANCj4+
IGN1cnJlbnRseSBkZXNjcmliaW5nLg0KPg0KPiBTb3JyeSB0byBzb3VuZCBjb25mdXNlZCwgYnV0
IG1heWJlIHlvdSBjb3VsZCBleHBsYWluIGEgYml0IGJldHRlci4gVG8gbXkgdW5kZXJzdGFuZGlu
ZywgaXQgaXMgdGhlIG9mZmVyZXIgdGhhdCBkZXNjcmliZXMgd2hhdCBpdCBvZmZlcnMgdG8gc2Vu
ZCwgYW5kIG5vdCB0aGUgb3RoZXIgd2F5IGFyb3VuZD8gDQo+IE1heWJlIEkgbWlzdW5kZXJzdGFu
ZCBzb21ldGhpbmcgdmVyeSBmdW5kYW1lbnRhbD8gU29ycnkgdG8gYXNrIHRoZXNlIGVsZW1lbnRh
cnkgcXVlc3Rpb25zLCBidXQgdGhpcyBpcyBpbXBvcnRhbnQgZm9yIHRoZSB0ZXh0Lg0KDQpJbiBT
RFAgT2ZmZXIvQW5zd2VyLCB0aGUgZGVmYXVsdCBpcyB0byBpbmRpY2F0ZSB3aGF0IHlvdSBhcmUg
d2lsbGluZyB0byBSRUNFSVZFIDopDQoNClR5cGljYWxseSB5b3VyIHJlY2VpdmluZyBjYXBhYmls
aXRpZXMgYWxzbyBpbXBsaWNpdGx5IGluZGljYXRlIHdoYXQgeW91IGFyZSBhYmxlIHRvIHNlbmQu
IEZvciBleGFtcGxlLCBpZiBJIGFtIGluZGljYXRpbmcgdGhhdCBJIGFtIHdpbGxpbmcgdG8gcmVj
ZWl2ZSBjb2RlYyBYIGl0IG5vcm1hbGx5IG1lYW5zIHRoYXQgSSBhbSBhbHNvIGFibGUgdG8gc2Vu
ZCBjb2RlYyBYLg0KDQogQnV0LCB0aGVyZSBhcmUgY2FzZXMgd2hlcmUgdGhhdCBpcyBub3QgdHJ1
ZSwgZXNwZWNpYWxseSB3aGVuIGl0IGNvbWVzIHRvIHZpZGVvIGNvZGVzIHdoZXJlIHlvdSB0eXBp
Y2FsbHkgaGF2ZSBtb3JlIHBhcmFtZXRlcnMgYXNzb2NpYXRlZCB3aXRoIHRoZSBjb2RlYywgYW5k
IG9uZSBuZWVkcyB0byBleHBsaWNpdGx5IGluZGljYXRlIHNlbmRpbmcgY2FwYWJpbGl0aWVzLiAN
Cg0KLS0tDQoNCj4+ICJUaGUgcmVjZWl2ZXIgU0hBTEwgaWdub3JlIGFueSB1bnJlY29nbml6ZWQg
cGFyYW1ldGVyIG9yIGludmFsaWQgDQo+PiBwYXJhbWV0ZXIgdmFsdWUuIg0KPj4gDQo+PiBGaXJz
dCwgSW4gbXkgb3BpbmlvbiBpbnZhbGlkIHBhcmFtZXRlcnMgdmFsdWVzIHNoYWxsIHRyaWdnZXIg
YW4gZXJyb3IuDQo+PiANCj4+IFNlY29uZCwgd2hhdCBpcyBhbiB1bnJlY29nbml6ZWQgcGFyYW1l
dGVyPw0KPg0KPiBJIHdvbmRlciB3aHkgd2UgbmVlZCB0byBzcGVjaWZ5IHRoaXMsIGkuZS4gd2hh
dCBhIHJlY2VpdmUgZG9lcyBhYm91dCANCj4gcGFyYW1ldGVycyBpdCBkb2VzIG5vdCByZWNvZ25p
emU/IEVzc2VudGlhbGx5LCB0aGlzIGlzIGEgcHJvYmxlbSBvZiANCj4gImZvcmV3YXJkIGNvbXBh
dGliaWxpdHkiLiBXb3VsZG4ndCBpdCBiZSBhIG1hdHRlciBvZiBpbXBsZW1lbnRhdGlvbiB3aGV0
aGVyIHRoZSByZWNlaXZlciBhY2NlcHRzIGFuIG9mZmVyIChub3RlIHdlbGwsIHRoZSByZWNlaXZl
ciksIGFuZCBhdHRlbXB0cyB0byBkZWNvZGUgYSBzdHJlYW0gb24gYSAiYmVzdCBlZmZvcnQiIGJh
c2lzLCBrZWVwaW5nIGluIG1pbmQgdGhhdCB0aGUgc3RyZWFtIGl0c2VsZiBpbmNsdWRlcyBhZGRp
dGlvbmFsIG1lYW5zIHRvIGlkZW50aWZ5IHJlcXVpcmVkIGNhcGFiaWxpdGllcyBuZWNlc3Nhcnkg
Zm9yIGEgc3VjY2Vzc2Z1bCBkZWNvZGUuDQo+DQo+IElmIHRoYXQgaXMgbm90IGFuIG9wdGlvbiwg
d2Ugd291bGQvY291bGQgbmVlZCBtZWFucyB0byBpZGVudGlmeSB0aGUgDQo+IHR5cGUgb2YgcGFy
YW1ldGVycyBpbiBhIGZvcmV3YXJkIGNvbXBhdGlibGUgd2F5LiBJLmUuLCBjb252ZW50aW9ucyBi
eSB3aGljaCB3ZSB3b3VsZCBpZGVudGlmeSBpbiB0aGUgZnV0dXJlIHBhcmFtZXRlcnMgYSByZWNl
aXZlciBjYW4gc2FmZWx5IGlnbm9yZSBhbmQgYXR0ZW1wdCB0byBkZWNvZGUsIGFuZCBwYXJhbWV0
ZXJzIGEgcmVjZWl2ZXIgY2Fubm90IHNhZmVseSBpZ25vcmUuDQoNCkkgdGhpbmsgaXQgaXMgZmlu
ZSB0byBzYXkgdGhhdCB1bnJlY29nbml6ZWQgcGFyYW1ldGVycyBzaGFsbCBiZSBpZ25vcmVkLiBJ
dCBpcyB0aGVuIHVwIHRvIGZ1dHVyZSBzcGVjaWZpY2F0aW9ucyB0byB3b3JyeSBhYm91dCBiYWNr
d2FyZCBjb21wYXRpYmlsaXR5LCByYXRoZXIgdGhhbiB0aGlzIHNwZWNpZmljYXRpb24gd29ycnlp
bmcgYWJvdXQgZm9yd2FyZCBjb21wYXRpYmlsaXR5Lg0KDQo+PiBBbHNvLCB0aGUgdGV4dCBkb2Vz
IG5vdCBzYXkgd2hhdCByZXN0cmljdGlvbnMgKGlmIGFueSkgdGhlcmUgYXJlIHdoZW4gDQo+PiBp
dCBjb21lcyB0byBtb2RpZnkgdGhlIHN0cmVhbSBkdXJpbmcgYSBzZXNzaW9uLiBJcyBpdCBhbGxv
d2VkIHRvIA0KPj4gbW9kaWZ5IGFueS9hbGwgY2hhcmFjdGVyaXN0aWNzPw0KPg0KPiBNeSB1bmRl
cnN0YW5kaW5nIGlzIHRoYXQgeW91IGNhbm5vdCBtb2RpZnkgY2hhcmFjdGVyaXN0aWNzIGR1cmlu
ZyBhIA0KPiBzZXNzaW9uLiBJZiB5b3UgbmVlZCB0byBtb2RpZnksIHlvdSBuZWVkIHRvIHNldHVw
IGEgbmV3IHNlc3Npb24gYW5kIA0KPiBjYW5jZWwgdGhlIGN1cnJlbnQgb25lLiBGb3IgSlBFRyBY
UyBzdHJlYW0gZGVjb2RlcnMsIG9uZSBjYW5ub3QgZXhwZWN0IHRoYXQgYW4gaW5zdGFuY2lhdGVk
IGRlY29kZXIgY2FuIGRlY29kZSBmcm9tIG1vZGlmaWVkIHBhcmFtZXRlcnMgaW4gbWlkLXN0cmVh
bSBsZXZlbC4gVGhhdCBpcywgaWYgeW91IHN0YXJ0IGRlY29kaW5nIGluIGZ1bGwtSEQsIGFuZCB0
aGVuIHN0cmVhbSBwYXJhbWV0ZXJzIGJlY29tZSA4SywgdGhlIGRlY29kZXIgd2lsbCBoYXZlIHRv
IGFib3J0Lg0KDQpUaGVzZSBraW5kIG9mIHRoaW5ncyBuZWVkIHRvIGJlIHNwZWNpZmllZC4gSSBk
b24ndCB0aGluayBpdCBuZWVkcyB0byBiZSBmb3JiaWRkZW4gdG8gdHJ5IHRvIG1vZGlmeSBzb21l
dGhpbmcsIGJlY2F1c2UgdGhlcmUgY291bGQgYmUgdGV4dCB0aGF0IHN0cm9uZ2x5IHJlY29tbWVu
ZHMgYWdhaW5zdCBkb2luZyBpdC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkF1ZGlvL1ZpZGVvIFRyYW5z
cG9ydCBDb3JlIE1haW50ZW5hbmNlDQphdnRAaWV0Zi5vcmcNCmh0dHBzOi8vdXJsZGVmZW5zZS5w
cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlz
dGluZm9fYXZ0JmQ9RHdJQ0FnJmM9ZXVHWnN0Y2FURGxsdmltRU44YjdqWHJ3cU9mLXY1QV9DZHBn
blZmaWlNTSZyPUxUeFVHdWtMQ0VmRVVkb19icTA0OFEmbT1MdGVmUWlMaGRyWHdVeWNhaDdabXNh
eWtfZHRIRi1oTUVCd0hvNkRwZXQwJnM9MXZaVHVGakktUWJleFA1b1g5cGdhMzVkWlp6dGhYR2du
N1M4WmdvZDlMRSZlPQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UNCmF2dEBpZXRm
Lm9yZw0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB
X193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19hdnQmZD1Ed0lDQWcmYz1ldUdac3RjYVRE
bGx2aW1FTjhiN2pYcndxT2YtdjVBX0NkcGduVmZpaU1NJnI9TFR4VUd1a0xDRWZFVWRvX2JxMDQ4
USZtPUx0ZWZRaUxoZHJYd1V5Y2FoN1ptc2F5a19kdEhGLWhNRUJ3SG82RHBldDAmcz0xdlpUdUZq
SS1RYmV4UDVvWDlwZ2EzNWRaWnp0aFhHZ243UzhaZ29kOUxFJmU9DQpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENv
cmUgTWFpbnRlbmFuY2UNCmF2dEBpZXRmLm9yZw0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p
bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19h
dnQmZD1Ed0lHYVEmYz1ldUdac3RjYVREbGx2aW1FTjhiN2pYcndxT2YtdjVBX0NkcGduVmZpaU1N
JnI9TFR4VUd1a0xDRWZFVWRvX2JxMDQ4USZtPVZ2c2E3dUZBNXowRFduQlNvTkVudmFfNGlqNXJi
Y1FHT3dMcF9pLTN6N3cmcz1vaUwycGRsN2hfNkxWWS00RTg4aFZWSTFOb0RXczZqQk9MYjFyV3JB
X25JJmU9DQo=


From nobody Mon May 31 07:10:36 2021
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08173A198E for ; Mon, 31 May 2021 07:10:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level: 
X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQSaiIoND8HN for ; Mon, 31 May 2021 07:10:29 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150074.outbound.protection.outlook.com [40.107.15.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06D473A198C for ; Mon, 31 May 2021 07:10:28 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NxbuvmaqrPc3xzHhQlZ2cOG8rrvX6ymxvGwsOh4LOBFwk+vLH078TSMxeaHvOFRDk8WwM/NTaFR+KkVpHsSllbgUENECc6Y10QKBFh/MBnRJjbk768a4+SvTHWLCt/cqMrUYYxh352lW10omKpEw/SGOgm98yeHihdUAY+uHwC6y5gfgfYUE3ZpdKI3Yj77BDfF7sn/yuQ+UEmJiDD/WeOUDwiqbylBWl05Bzx4zxk4ur6WpIMUrML+FQbBkU11JgTjN+yvVEp+xy1oWBg9Vu46uiefR4B06zfkn2Eba6PfGW5qdo68sAEZYh6vbr6Ec7ONi0fh8opGTgEnglb867Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vCF3zTBxEm9gtpGHHjSoWeJb2tTJcFjnVoWobPTZv/A=; b=Cmp1PAQbUC6uMoX6t1lK71moCiILOP04p2qhMeV3S6hs5xMAcCfh2HCzmI34F/aj/lcT/0Fz0l7rBL0HwPREtNfOJlDniaOowZI3fIeush8AMXtkA9dfUq+np+waH9PwRCmosa/i0BMUoXsvCVnq6MiCB9aB0K/y5tQhZKp+AAaEBa1Z+Y3mmPu4PNiJBtY0Do3ujzfDa3kMBFWOqL/f+wxocz0YT8rM85mrgKXFL9mJuGI2tAXNh7pEshVs6OvD0v/i4g/MYnAU/RxBd44A+WsahlzPW0dVzJKi1iFyaMbUW+7TGNjH+k2jyt4otbHhvJDMRZRQiROUEtrhThL41Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vCF3zTBxEm9gtpGHHjSoWeJb2tTJcFjnVoWobPTZv/A=; b=O+c3MRFZu1f/aYfhKvNuDYblmhXL58bY6gSz6pE6hpTXVibM7Oeq3djRMVzsgd09Krvx2NvlEpTgNYvLusJt3e4pdQY/CtHPNCCwoN38jY/sM2uKq2aZQsuHaebmP21ZigvUdoaGdt9CaMTF2PtZL+2m32JZo/wG9ok7sm+IBJQ=
Received: from AM0PR07MB3860.eurprd07.prod.outlook.com (2603:10a6:208:4c::18) by AM9PR07MB7073.eurprd07.prod.outlook.com (2603:10a6:20b:2d1::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.12; Mon, 31 May 2021 14:10:26 +0000
Received: from AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::b10f:ebc0:80d:db2]) by AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::b10f:ebc0:80d:db2%7]) with mapi id 15.20.4195.017; Mon, 31 May 2021 14:10:26 +0000
From: Christer Holmberg 
To: Tim Bruylants , Thomas Richter , "avt@ietf.org" 
CC: Jean-Baptiste Lorent 
Thread-Topic: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
Thread-Index: AddLKBOH9HzaEV4jTtmQ8TPYzmKsqwFVwo+gABfRKwAAFpWSgABEymJQAABwR+AAT0NxwAAES3xQAAEQhVAAkqc4oAAOiNkw
Date: Mon, 31 May 2021 14:10:25 +0000
Message-ID: 
References:    <7aa5e890-47c5-cdb7-5657-26864cec3d4c@iis.fraunhofer.de>      
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: intopix.com; dkim=none (message not signed) header.d=none;intopix.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [80.248.247.159]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f5d54d57-468a-439f-15b2-08d9243dd689
x-ms-traffictypediagnostic: AM9PR07MB7073:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: MBJ1bx7hyo91BRCRU7Q6RHqM/cuoKzF+sSrGM5oq8XZA5bCCd5qvJzNMH4q/JcQaRDv5m9GiCTiDF/tMSZbO6lWp8ynEy3eOPhS+sYLK4Gd1bfz36xWrBD/edgDH58Yn1PVNrScNn2KdsjlpGf6zvMiACmeRbBGShJiBvC2zxcyxH3auGV6oak2/n89JHONlD3nzn93/Y6rc4qe9tsYzCOxm13hbOp+2ENsRy3mzcmK0RxT0+jTAAsx9g+bAY3XvKrB9xSTawCpO6dEOKTeKSeR9ubFltFlSqFGm6eEPMaxLIhnhFqfSZsrbt7cTvawjHC56UIM3Vb/00qDYpk3Zbari1RgQppwGpJO+QkXxsU11Eowfh4pqaK7vn1gCwuDpjK/vzyUj5GQoApN6uj966aDCIAY5IjR9T2x+fvyPj8c/rLYKU8QU6XIJGIR3mzwqVWGQfHYCrxKRHR4+viS5bkF1CIDCFFyeJwe46AfykkcHOWx28IlPDWqC+mnOnkUd6nOI0g1tSbZQW73w8ol4G9U+LiINKSEaJGrNtdRrzdRIoykJQib86Q/hbd2YFwnxR+kNIadGc0E26d6qyntb+sliSfkk6fzKTfytH/NZZ+m4HDZCSIHE+3vNEkXJIL2XonTK6qpkmgDNrNOpAAgbadDbL8Fti4lEjRAjk2e6RbQ5Dfutnym8OMoIR6MrXcG9Yo5IXMW3j/j4oevz9fwV9mzpp00AacEbfmJ+v+R3FZ4=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:AM0PR07MB3860.eurprd07.prod.outlook.com; PTR:; CAT:NONE;  SFS:(4636009)(346002)(39860400002)(366004)(376002)(396003)(136003)(66446008)(76116006)(64756008)(33656002)(66946007)(66476007)(86362001)(66556008)(83380400001)(7696005)(6506007)(9686003)(8676002)(316002)(53546011)(478600001)(71200400001)(55016002)(2906002)(8936002)(5660300002)(30864003)(186003)(122000001)(966005)(44832011)(110136005)(38100700002)(4326008)(52536014)(26005); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?utf-8?B?eXNCdnBNNnpQOFd6WXVCRHBrTVRXSng5R2tRMkRlcit1NVNsREFKaEFJbkYr?= =?utf-8?B?RjlQaGhwWFlzNWIvSFBITXJiU3dGa0s2S2FyY2hUZzJ4ajFBZERpQXVBT0ZR?= =?utf-8?B?UEM0UnVHRDA1c2ZmSE8rMDVwWU9acnNJMHdudzZXNWt4YjhRenNOVEVFN1o2?= =?utf-8?B?YldqTVdXZjdvQTVjaW5sR0ZFSVEzeU1rdkdobEhMSTBwaUZaRWxIWEc4c2M0?= =?utf-8?B?L1NQaU1yWUVhMVU5UTRmaXJMTzRuYkZZS1BweXFsd3dTWG9WTHZDUzJzU1k5?= =?utf-8?B?MWk2T2YrTjFaWTI4Njdxbzl5bjNGMXAwaGxaSTZEbThCajZOSlp0NHpZQjFV?= =?utf-8?B?NWpGMUU5RXVNMjNKbkhPRDJmcXpSc3NmcElQb0dKNlZWQVZwZEZkMnZ6RktY?= =?utf-8?B?c1pqSlNCRHFOOUVkTmJNRUkwUkVaanRDSU5CWms2dHNzWG1JRjNjY0k5UEpz?= =?utf-8?B?aHJDc3Eza1R6ekZRTElUTGFHaEFZenBrVFFuTXF2YURYUU9XZk0zREYyeWhB?= =?utf-8?B?aVFOUlQ4NzRITndHcitjRWswVW9yMlRCWUdydVJMUkpxazZFWEIxa1VROFpU?= =?utf-8?B?SGo4SmFqY3hTaEpNQlRKMUtsWnR6YVUvMFZVRTg5SlVMNTdYVkNxNWlNTVRs?= =?utf-8?B?UGtYK0p1eVJtOEFXUlMyeEV1NStxVzREZFlDTDJvNEtGZUhXaFRFL2NuaDRm?= =?utf-8?B?MXhDeGtTeXZuRThvL3BBblhBemRJd0hTczQzeHRJNVcwSTRvZkgxR2R2UUxK?= =?utf-8?B?cyt2NHNDcGpETXBRN010NjcwVmNsVHJySFZERkhjY0ZIV0ZBR3dDREV3SkRy?= =?utf-8?B?bUFFdStpNys2ejkxQmJGTFp3RGJaSUgxUmdFZWN5MFE4RWszNGFaYXZnMlpU?= =?utf-8?B?MEd4VFFyTWY5UEFPdUNmUXVYWVlrR09XWEt5aGhCSDdzZDlES0NOM2dNOTJO?= =?utf-8?B?OGQ0Y1BXaGx1RC8rL3pwZjhGYzQ5SmoyWVhNMEpmNVVXUzA4enE5V1hlcG9K?= =?utf-8?B?WGl1Q0NPL0dSME12ZTF3cEFxcUVYazZZZ0luWnowbzhNdVB1WkZvR1FuYUh0?= =?utf-8?B?WVpaNm9zUlRNRHJMcGEranNPNGZLTHBTUmVvT2ZNL2liZThSYW9ITi96UWsv?= =?utf-8?B?T0lCcnhBZmQxVzMrWWpIblpnak1SQW95WUk1TnBkS0J4dC9vNWNBVFU4Yk10?= =?utf-8?B?OTUyeS9UdE8yQ1BYUWU2T2pnaElsZW1HTzIrTGpwMG5rdTlpTmphRUF6QWNG?= =?utf-8?B?YUZVempBTlJiMFFKdHdqM3BtWGtNRjY5SXpadTh5TktQVHZrOHhtRU9UUEo3?= =?utf-8?B?dGRVM3dYak1xaWd5NjFBOHMvQ2ZnaUNsVWdJN2hiV3lNUmVUMTJoaXNNNlhi?= =?utf-8?B?OWdCeHI0SFFybTJIWFZEWW1lMitLaGppdVZmOXk4WFpJSWE1akhPdGoycHZN?= =?utf-8?B?RWdsRXp4SlVsdUd1a3Q1UmJzU2tqVmZ5aFZFdjFrRUlOeUxZL3loMDY4UGxq?= =?utf-8?B?R201RVUwbHNkbzhOTjRSRE9KR2hEelJFVFF6L0lhdUlOb0hBWmxjOEFNYnVt?= =?utf-8?B?eU1FK2xkVk5BWnlmYTJFQzQzVGFlb3AzMGczNUttd2lsSFNjd3NBNGRFK3Bn?= =?utf-8?B?V1BlTGdUK3dxbjNDaHFENmxvT0xkS3lUVW5rUHRZQTV3VEROUlN3aVpCWjJC?= =?utf-8?B?REptQmtDY2M1VEpVU05pRUM4Zy9HYnZoK2Z2dFh3eW5ySFhhWUdhYk5nZnFB?= =?utf-8?Q?2YvK2Ubtln55kKfCcJMHog7WfYeVE8c/MX2C4zL?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB3860.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f5d54d57-468a-439f-15b2-08d9243dd689
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2021 14:10:25.9439 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: pc/TlLEw5S2aOE97l4+IyHf64pJmMzGIuEteUa9ma7xUkkAnTtFptL6M4YNR6Ll3UdC22/RAX0otnTQUhPk9+mKBBYIOFs2S+7rLCIKny/E=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR07MB7073
Archived-At: 
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 May 2021 14:10:35 -0000

SGkgVGltLA0KDQo+QmVmb3JlIEkgdXBsb2FkIGEgbmV3IGRyYWZ0IHRvIGFkZHJlc3MgdGhlIFNE
UCwgSSB3b3VsZCBsaWtlIHlvdSB0byByZXZpc2UgdGhlIGZvbGxvd2luZyB0ZXh0Lg0KPg0KPkFz
IHlvdSBzdGF0ZWQsIHdoZW4gZGVzY3JpYmluZyB0aGUgU0RQIG9mZmVyL2Fuc3dlciBtb2RlbCwg
dGhlIGRyYWZ0IG5lZWRzIHRvIGFkZHJlc3MgdGhlIDUgZm9sbG93aW5nIHRvcGljczoNCj5YLjEg
R2VuZXJpYyBTRFAgQ29uc2lkZXJhdGlvbnMNCj5YLjIuICBHZW5lcmF0aW5nIHRoZSBJbml0aWFs
IFNEUCBPZmZlcg0KPlguMy4gIEdlbmVyYXRpbmcgdGhlIFNEUCBBbnN3ZXINCj5YLjQuICBPZmZl
cmVyIFByb2Nlc3Npbmcgb2YgdGhlIFNEUCBBbnN3ZXIgWC41LiAgTW9kaWZ5aW5nIHRoZSBTZXNz
aW9uDQo+DQo+T3VyIHF1ZXN0aW9uOiBJcyB0aGlzIHN1ZmZpY2llbnRseSBkZXNjcmliZWQgaW4g
UkZDMzI2NCBhbmQgaXMgaXQgb2sgdG8gcmVmZXIgdG8gdGhhdCBSRkMgd2l0aCBzb21lIGV4dHJh
IGNsYXJpZmljYXRpb25zPyBSRkMzMjY0IHNlZW1zIHRvIGJlIHdoYXQgd2UgaW50ZW5kICJpZiIg
c2RwIG9mZmVyL2Fuc3dlciBpcyB1c2VkLiBUaGlzIHdvdWxkIHJlc3VsdCBpbiB0aGUgZm9sbG93
aW5nIHRleHQ6DQo+DQo+Ly8tLS0gU05JUFBFVA0KPjguMi4gIFVzYWdlIHdpdGggU0RQIE9mZmVy
L0Fuc3dlciBNb2RlbA0KPg0KPiAgIFdoZW4gSlBFRyBYUyBpcyBvZmZlcmVkIG92ZXIgUlRQIHVz
aW5nIFNEUCBpbiBhbiBvZmZlci9hbnN3ZXIgbW9kZWwNCj4gICBbUkZDMzI2NF0gZm9yIG5lZ290
aWF0aW9uIGZvciB1bmljYXN0IHVzYWdlLCB0aGUgZm9sbG93aW5nDQo+ICAgbGltaXRhdGlvbnMg
YW5kIHJ1bGVzIGFwcGx5Og0KPg0KPiAgICAgIFRoZSAiYT1mbXRwIiBhdHRyaWJ1dGUgU0hBTEwg
YmUgcHJlc2VudCBzcGVjaWZ5aW5nIHRoZSByZXF1aXJlZA0KPiAgICAgIHBhcmFtZXRlciAidHJh
bnNtb2RlIiBhbmQgTUFZIHNwZWNpZnkgYW55IG9mIHRoZQ0KPiAgICAgIG9wdGlvbmFsIHBhcmFt
ZXRlcnMsIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDcuMS4NCj4NCj4gICAgICBBbGwgcGF5bG9h
ZCBwYXJhbWV0ZXJzIGFyZSBkZWNsYXJhdGl2ZSwgbWVhbmluZyB0aGF0IHRoZXkgZGVzY3JpYmUN
Cj4gICAgICBwcm9wZXJ0aWVzIG9mIHRoZSBwYXlsb2FkLg0KPg0KPiAgICAgIEEgcmVjZWl2ZXIg
b2YgdGhlIFNEUCBpcyByZXF1aXJlZCB0byBzdXBwb3J0IGFsbCBwYXJhbWV0ZXJzIGFuZA0KPiAg
ICAgIHZhbHVlcyBvZiB0aGUgcGFyYW1ldGVycyBwcm92aWRlZDsgb3RoZXJ3aXNlLCB0aGUgcmVj
ZWl2ZXIgU0hBTEwNCj4gICAgICByZWplY3QgdGhlIHNlc3Npb24uICBJdCBmYWxscyBvbiB0aGUg
Y3JlYXRvciBvZiB0aGUgc2Vzc2lvbiB0byB1c2UNCj4gICAgICB2YWx1ZXMgdGhhdCBhcmUgZXhw
ZWN0ZWQgdG8gYmUgc3VwcG9ydGVkIGJ5IHRoZSByZWNlaXZpbmcNCj4gICAgICBhcHBsaWNhdGlv
bi4NCj4vLy0tLSBTTklQUEVUDQo+DQo+IEZlZWRiYWNrIHdvdWxkIGJlIHZlcnkgd2VsY29tZS4N
Cg0KQSBjb3VwbGUgb2YgY29tbWVudHM6DQoNCg0KUTE6DQoNCiJBbGwgcGF5bG9hZCBwYXJhbWV0
ZXJzIGFyZSBkZWNsYXJhdGl2ZSwgbWVhbmluZyB0aGF0IHRoZXkgZGVzY3JpYmUgcHJvcGVydGll
cyBvZiB0aGUgcGF5bG9hZC4iDQoNCkkgZG9uJ3QgdGhpbmsgeW91IG5lZWQgdG8gc2F5IHRoYXQu
DQoNCkJhc2VkIG9uIG91ciBlYXJsaWVyIGRpc2N1c3Npb25zLCBJIHRoaW5rIHdoYXQgeW91IG5l
ZWQgdG8gcG9pbnQgb3V0IGlzIHRoYXQgdGhlIGZtdHAgYXR0cmlidXRlIGlzIHVzZWQgdG8gaW5k
aWNhdGUgU0VORElORyBjYXBhYmlsaXRpZXMuDQoNCi0tLS0NCg0KUTI6DQoNCiJBIHJlY2VpdmVy
IG9mIHRoZSBTRFAgaXMgcmVxdWlyZWQgdG8gc3VwcG9ydCBhbGwgcGFyYW1ldGVycyBhbmQNCnZh
bHVlcyBvZiB0aGUgcGFyYW1ldGVycyBwcm92aWRlZDsgb3RoZXJ3aXNlLCB0aGUgcmVjZWl2ZXIg
U0hBTEwNCnJlamVjdCB0aGUgc2Vzc2lvbi4gIEl0IGZhbGxzIG9uIHRoZSBjcmVhdG9yIG9mIHRo
ZSBzZXNzaW9uIHRvIHVzZQ0KdmFsdWVzIHRoYXQgYXJlIGV4cGVjdGVkIHRvIGJlIHN1cHBvcnRl
ZCBieSB0aGUgcmVjZWl2aW5nDQphcHBsaWNhdGlvbi4iDQoNCkluc3RlYWQgb2YgInJlY2VpdmVy
IiwgSSB3b3VsZCBzYXkgYW5zd2VyZXIuDQoNCkluc3RlYWQgb2YgImNyZWF0b3IiLCBJIHdvdWxk
IHNheSBvZmZlcmVyLg0KDQpBbHNvLCBhc3N1bWluZyB0aGUgYW5zd2VyZXIvcmVjZWl2ZXIgYWNj
ZXB0cyB0aGUgb2ZmZXIsIHRoZXJlIGlzIG5vIHRleHQgb24gd2hhdCBpdCBpbmNsdWRlcyBpbiB0
aGUgYW5zd2VyLiBEb2VzIHRoZSBhbnN3ZXJlciBhbHNvIGluY2x1ZGUgYW4gZm10cCBhdHRyaWJ1
dGU/IElmIHNvLCB3aGF0IHZhbHVlcyBkb2VzIGl0IGluY2x1ZGU/DQoNClJlZ2FyZHMsDQoNCkNo
cmlzdGVyDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBhdnQgPGF2
dC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgVGltIEJydXlsYW50cw0KU2VudDogRnJp
ZGF5IDI4IE1heSAyMDIxIDEyOjIxDQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhv
bG1iZXJnQGVyaWNzc29uLmNvbT47IFRob21hcyBSaWNodGVyIDx0aG9tYXMucmljaHRlckBpaXMu
ZnJhdW5ob2Zlci5kZT47IGF2dEBpZXRmLm9yZw0KQ2M6IEplYW4tQmFwdGlzdGUgTG9yZW50IDxq
Yi5sb3JlbnRAaW50b3BpeC5jb20+DQpTdWJqZWN0OiBSZTogW0FWVENPUkVdIFNEUCBkaXJlY3Rv
cmF0ZSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1qcGVneHMtMTMNCg0KSGkgQ2hy
aXN0ZXIsDQoNClRoYW5rcyBmb3IgdGhlIHF1aWNrIHJlc3BvbnNlLCB3ZSByZWFsbHkgYXBwcmVj
aWF0ZSB5b3VyIHRpbWUuDQoNClNvLCBsZXQgbWUgZWxhYm9yYXRlIGEgYml0Og0KDQo+PiBGaXJz
dCwgcmVnYXJkaW5nIFJGQyA4NDUwLCB0aGF0IHNwZWNpZmljYXRpb24gd2FzIHByb2JhYmx5IG5l
dmVyIHJldmlld2VkIGJ5IHRoZSBTRFAgZGlyZWN0b3JhdGUsIHNvIEkgY2FuJ3QgcmVhbGx5IGNv
bW1lbnQgb24gdGhhdC4gQnV0LCBJIHNlZSB0aGF0IHRoZSBSRkMgZS5nLiwgc2F5cyBub3RoaW5n
IGFib3V0IHdoZXRoZXIgdGhlIFNEUCBpbmRpY2F0ZXMgc2VuZGluZyBvciByZWNlaXZpbmcgY2Fw
YWJpbGl0aWVzLg0KDQpPaywgSSB1bmRlcnN0YW5kIHRoYXQgUkZDIDg0NTAgbWlnaHQgbm90IGJl
IGVudGlyZWx5IGNsZWFyIG9yIHdlbGwgd3JpdHRlbiBvbiB0aGUgU0RQIHBhcnQuDQoNCj4+IFNl
Y29uZCwgbm9ib2R5IG1hbmRhdGVzIHlvdSB0byB1c2UgU0RQLCBhbmQgbW9zdCBwYXJ0IG9mIHRo
ZSBzcGVjIGlzIHByb3RvY29sIGluZGVwZW5kZW50LiBCdXQsIHRoZSAiU0RQIE9mZmVyL0Fuc3dl
ciIgc2VjdGlvbiBkZXNjcmliZXMgdGhlIFNEUCBvZmZlci9hbnN3ZXIgcHJvY2VkdXJlcywgKklG
KiB5b3UgY2hvb3NlIHRvIHVzZSB0aGF0IG1lY2hhbmlzbSBmb3IgbmVnb3RpYXRpbmcgdGhlIHNl
c3Npb24uDQoNCk9rLiBUaGF0IEkgdW5kZXJzdGFuZC4gSW4gb3VyIGNhc2UsIFNEUCBhcyB0aGUg
c2Vzc2lvbiBwcm90b2NvbCBpcyBub3QgY3JpdGljYWwsIGJ1dCBzdGlsbCBhIG5pY2UgdG8gaGF2
ZS4gRG8geW91IGFncmVlPyBPciBkbyB5b3UgcmVjb21tZW5kIHdlIHJlbW92ZSB0aGUgU0RQIG9m
ZmVyL2Fuc3dlciBzZWN0aW9uPw0KDQpXaGF0IHdlIGRvIG5lZWQgdG8gc2F5IGlzIGhvdyB0byBt
YXAgcGFyYW1ldGVycyBpbnRvIGFuIFNEUC1jb21wbGlhbnQgZm9ybWF0IGRlc2NyaXB0aW9uLCBm
b3IgdGhlIHNhbWUgcmVhc29ucyBhcyBSRkMgODQ1MCBhbmQgbWFueSBvdGhlciB2aWRlbyBwYXls
b2FkIFJGQydzIChWUDgsIFZQOSwgSC4yNjQvQVZDLCBILjI2NS9IRVZDLCBldGMpLiBUaGlzIGFs
bG93cyB1c2luZyBtYW55IG90aGVyIHNlc3Npb24gbmVnb3RpYXRpb24gcHJvdG9jb2xzIHRoYXQg
cmVseSBvbiB0aGUgU0RQIGRlc2NyaXB0aW9uLg0KDQo+PiBUaGlyZCAuLi4uDQoNCkkgYmVsaWV2
ZSB3aGF0IGlzIHZlcnkgaW1wb3J0YW50IHRvIGV4cGxhaW4gaXMgdGhhdCBhbGwgb2Ygb3VyIHBh
cmFtZXRlcnMgYXJlIGRlY2xhcmF0aXZlLCBtZWFuaW5nIHRoYXQgdGhleSBkZXNjcmliZSBleGFj
dCBiaXRzdHJlYW0gcHJvcGVydGllcywgYW5kIG5vdCByZWNlaXZlciBjYXBhYmlsaXRpZXMuIFRo
ZSBTRFAgcGFyYW1ldGVycyBjYW4gYmUgdXNlZCB0byBjb21tdW5pY2F0ZSBiZXR3ZWVuIHNlbmRl
ci9yZWNlaXZlciB3aGF0IHRoZXkgd2lzaCB0byBleGNoYW5nZSBiZWZvcmUgc2VuZGluZyBhY3R1
YWwgcGF5bG9hZCwgYnV0IG5vbmUgb2YgdGhlc2UgcGFyYW1ldGVycyBvciB2YWx1ZXMgYXJlICJk
b3duZ3JhZGFibGUiIG9yICJpbmNsdXNpdmUgY2FwYWJpbGl0eSBzZXRzIi4gWFMgZG9lcyBub3Qg
aGF2ZSBzdWNoIGNvbmNlcHRzLCBhcyBpdCBpcyBhIGxvdy1jb21wbGV4aXR5IGNvZGVjLCBpbnRl
bmRlZCBwcmltYXJpbHkgdG8gcmVwbGFjZSB1bmNvbXByZXNzZWQgdmlkZW8gc3RyZWFtcy4NCg0K
U29tZWhvdywgdGhpcyByYWlzZXMgdGhlIGZvbGxvd2luZzoNCg0KWC4xIEdlbmVyaWMgU0RQIENv
bnNpZGVyYXRpb25zDQogIEkgYmVsaWV2ZSBoZXJlIHdlIGV4cGxhaW4gdGhhdCBwYXJhbWV0ZXJz
IGFyZSBkZWNsYXJhdGl2ZSBhbmQgcmVwcmVzZW50IGJpdHN0cmVhbS9wYXlsb2FkIHZhbHVlcy9z
ZXR0aW5ncy4gU28gYm90aCBzaWRlcyBjYW4gdXNlIHRoZXNlIHRvIGluZGljYXRlIHdoYXQgdGhl
IHBheWxvYWQgd2lsbCBsb29rIGxpa2UuDQoNClguMi4gIEdlbmVyYXRpbmcgdGhlIEluaXRpYWwg
U0RQIE9mZmVyDQogIE5vdCBtdWNoIHRvIHNheSBoZXJlLiBBcyBJIHVuZGVyc3RhbmQgYW4gU0RQ
IHNlc3Npb24gY2FuIGJlIGluaXRpYXRlZCBmcm9tIGVpdGhlciByZWNlaXZlciBvciBzZW5kZXIg
c2lkZXM/IFNvLCB0aGV5IGp1c3Qgc2VuZCBhIHZhbGlkIG1lZGlhIGRlc2NyaXB0aW9uIG9mIHRo
ZSBjb250ZW50IHRoZXkgd2FudCB0byBleGNoYW5nZS4gSWYgZWl0aGVyIHNpZGUgY2Fubm90IGhh
bmRsZSBjZXJ0YWluIHBheWxvYWQgc2V0dGluZ3MsIHRoZW4gaXQgc2hvdWxkIHJlamVjdCB0aGUg
b2ZmZXIgKG9yIGFuc3dlcikuIEFuIG9mZmVyZXIganVzdCBzZW5kcyB3aGF0IGl0IHdhbnRzIHRv
IHJlY2VpdmUgb3Igc2VuZC4NCg0KWC4zLiAgR2VuZXJhdGluZyB0aGUgU0RQIEFuc3dlcg0KICBJ
IGRvbid0IHRoaW5rIHRoZXJlIGlzIGFueXRoaW5nIHNwZWNpYWwgdG8gbWVudGlvbiBoZXJlPyBU
aGUgYW5zd2VyZXIgdGFrZXMgdGhlIGRlY2xhcmF0aXZlIHBhcmFtZXRlcnMgYW5kIGVpdGhlciBh
Y2NlcHRzIG9yIHJlamVjdHMgdGhlIHNlc3Npb24uIEl0IHNob3VsZCBOT1QgbW9kaWZ5IHRoZSBv
ZmZlciBpbiBhbnkgd2F5Lg0KDQpYLjQuICBPZmZlcmVyIFByb2Nlc3Npbmcgb2YgdGhlIFNEUCBB
bnN3ZXINCiAgSSBkb24ndCB0aGluayB0aGVyZSBpcyBhbnl0aGluZyBzcGVjaWFsIHRvIG1lbnRp
b24gaGVyZT8gSWYgdGhlIGFuc3dlciBhY2NlcHRlZCB0aGUgb2ZmZXIsIHRoZW4gdGhlIHN0cmVh
bSBjYW4gc3RhcnQuDQoNClguNS4gIE1vZGlmeWluZyB0aGUgU2Vzc2lvbg0KICBNb2RpZnlpbmcg
dGhlIHNlc3Npb24gaXMgcG9zc2libGUsIGJ1dCB0aGlzIGlzIHZlcnkgaW1wbGVtZW50YXRpb24g
c3BlY2lmaWMuIEJhc2ljYWxseSwgbW9kaWZ5aW5nIGEgc2Vzc2lvbiBpcyB2ZXJ5IHNpbWlsYXIg
dG8gY3JlYXRpb24gb2YgYSBuZXcgc2Vzc2lvbi4gQm90aCBzaWRlcyBzaG91bGQgYWdyZWUgb24g
dGhlIHBheWxvYWQgdGhleSB3aWxsIGV4Y2hhbmdlLg0KDQoNCkknbSBzb3JyeSB0byBkcmFnIHRo
aXMgb3V0LCBidXQgSSB0aGluayB0aGF0IGhhdmluZyB0aGlzIGNvbnZlcnNhdGlvbiBieSBlbWFp
bCBpcyBtb3JlIGVmZmljaWVudCB0aGFuIHBvc3RpbmcgZHJhZnRzIPCfmIogSSBhcHByZWNpYXRl
IHlvdXIgZmVlZGJhY2suDQoNClRpbS4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
RnJvbTogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4N
ClNlbnQ6IEZyaWRheSAyOCBNYXkgMjAyMSAxMDozOQ0KVG86IFRpbSBCcnV5bGFudHMgPFRCUkBp
bnRvcGl4LmNvbT47IFRob21hcyBSaWNodGVyIDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu
dC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fdGhvbWFzLnJpY2h0ZXItNDBpaXMuZnJhdW5ob2Zlci5k
ZSZkPUR3SUdhUSZjPWV1R1pzdGNhVERsbHZpbUVOOGI3alhyd3FPZi12NUFfQ2RwZ25WZmlpTU0m
cj1MVHhVR3VrTENFZkVVZG9fYnEwNDhRJm09VnZzYTd1RkE1ejBEV25CU29ORW52YV80aWo1cmJj
UUdPd0xwX2ktM3o3dyZzPWF1ZUppb1RsdFkwNWt4ZkIyMVJGT3ZTUXN6OGx1bFRveVhRemJjdEpD
dmMmZT0+OyBhdnRAaWV0Zi5vcmcNCkNjOiBKZWFuLUJhcHRpc3RlIExvcmVudCA8amIubG9yZW50
QGludG9waXguY29tPg0KU3ViamVjdDogUkU6IFtBVlRDT1JFXSBTRFAgZGlyZWN0b3JhdGUgcmV2
aWV3IG9mIGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtanBlZ3hzLTEzDQoNCkhpLA0KDQpGaXJzdCwg
cmVnYXJkaW5nIFJGQyA4NDUwLCB0aGF0IHNwZWNpZmljYXRpb24gd2FzIHByb2JhYmx5IG5ldmVy
IHJldmlld2VkIGJ5IHRoZSBTRFAgZGlyZWN0b3JhdGUsIHNvIEkgY2FuJ3QgcmVhbGx5IGNvbW1l
bnQgb24gdGhhdC4gQnV0LCBJIHNlZSB0aGF0IHRoZSBSRkMgZS5nLiwgc2F5cyBub3RoaW5nIGFi
b3V0IHdoZXRoZXIgdGhlIFNEUCBpbmRpY2F0ZXMgc2VuZGluZyBvciByZWNlaXZpbmcgY2FwYWJp
bGl0aWVzLg0KDQpTZWNvbmQsIG5vYm9keSBtYW5kYXRlcyB5b3UgdG8gdXNlIFNEUCwgYW5kIG1v
c3QgcGFydCBvZiB0aGUgc3BlYyBpcyBwcm90b2NvbCBpbmRlcGVuZGVudC4gQnV0LCB0aGUgIlNE
UCBPZmZlci9BbnN3ZXIiIHNlY3Rpb24gZGVzY3JpYmVzIHRoZSBTRFAgb2ZmZXIvYW5zd2VyIHBy
b2NlZHVyZXMsICpJRiogeW91IGNob29zZSB0byB1c2UgdGhhdCBtZWNoYW5pc20gZm9yIG5lZ290
aWF0aW5nIHRoZSBzZXNzaW9uLg0KDQpUaGlyZCwgSSBkb24ndCB0aGluayB5b3UgbmVlZCB2ZXJ5
IG11Y2ggdGV4dC4gVGhlIGltcG9ydGFudCB0aGluZyBpcyB0byBzYXkgd2hhdCBpcyBwbGFjZWQg
aW4gb2ZmZXJzIGFuZCBhbnN3ZXJzLCB3aGV0aGVyIHRoZXJlIGFyZSBjb25zdHJhaW50cyB3aGVu
IGdlbmVyYXRpbmcgdGhlIGFuc3dlciwgYW5kIHdoZXRoZXIgdGhlcmUgYXJlIGNvbnN0cmFpbnRz
IHdoZW4gaXQgY29tZXMgdG8gbW9kaWZ5aW5nIHRoZSBzZXNzaW9uLiBBbmQsIHlvdSBkbyBOT1Qg
IG5lZWQgdG8gc3BlY2lmeSBIT1cgdG8gbW9kaWZ5IGEgc2Vzc2lvbiwgYnV0IHdoZXRoZXIgdGhl
cmUgYXJlIHBheWxvYWQtc3BlY2lmaWMgY29uc3RyYWludHMgd2hlbiBkb2luZy4NCg0KUmVnYXJk
cywNCg0KQ2hyaXN0ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRpbSBC
cnV5bGFudHMgPFRCUkBpbnRvcGl4LmNvbT4NClNlbnQ6IHBlcmphbnRhaSAyOC4gdG91a29rdXV0
YSAyMDIxIDkuNDkNClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp
Y3Nzb24uY29tPjsgVGhvbWFzIFJpY2h0ZXIgPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50
LmNvbS92Mi91cmw/dT1odHRwLTNBX190aG9tYXMucmljaHRlci00MGlpcy5mcmF1bmhvZmVyLmRl
JmQ9RHdJRkFnJmM9ZXVHWnN0Y2FURGxsdmltRU44YjdqWHJ3cU9mLXY1QV9DZHBnblZmaWlNTSZy
PUxUeFVHdWtMQ0VmRVVkb19icTA0OFEmbT1nZkI0UEYtdlZCVy1IVnhjU3hDeDA3TENoUTFDU2Vw
WU4zSm51dlBadmhnJnM9V2cwOGkzMjEzYkN5UDBZYjhIajVpaHBCV2otZGxyVm5LRGRqZ2dPSmJx
QSZlPT47IGF2dEBpZXRmLm9yZw0KQ2M6IEplYW4tQmFwdGlzdGUgTG9yZW50IDxqYi5sb3JlbnRA
aW50b3BpeC5jb20+DQpTdWJqZWN0OiBSRTogW0FWVENPUkVdIFNEUCBkaXJlY3RvcmF0ZSByZXZp
ZXcgb2YgZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1qcGVneHMtMTMNCg0KSGkgQ2hyaXN0ZXIsDQoN
CkknbSBhIGxpdHRsZSBiaXQgc3R1Y2sgaW4gaG93IHRvIHJlc29sdmUgYW5kIGFkZHJlc3MgeW91
ciBjb21tZW50cy4gT24gb25lIGhhbmQgSSB1bmRlcnN0YW5kIHRoYXQgd2Ugd2FudCB0aGUgdGV4
dCB0byBiZSBjbGVhciwgYnV0IG9uIHRoZSBvdGhlciBoYW5kIHdlIGRvIG5vdCB3YW50IHRvIHJl
cGVhdCBTRFAgc3BlY2lmaWNzIHRvbyBtdWNoLiBTRFAgaXMganVzdCBvbmUgd2F5IHRvIG5lZ290
aWF0ZSBhIHNlc3Npb24sIGFuZCBpbiB0aGUgY2FzZSBvZiBYUyBpdCBpcyBub3QgdGhlIG1vc3Qg
Y29tbW9ubHkgdXNlZCBvbmUuIFhTIGlzIG5vdCByZWFsbHkgaW50ZW5kZWQgZm9yIHRoZSBjbGFz
c2ljYWwgdmlkZW8tY2FsbCBjYXNlLCBidXQgcmF0aGVyIHRvIHN0cmVhbSBoaWdoLXF1YWxpdHkg
dmlkZW8gY29udGVudCBpbiBhIHByb2Zlc3Npb25hbCBlbnZpcm9ubWVudC4gSXQgY2FuIGJlIHVz
ZWQgZm9yIHZpZGVvIGNvbmZlcmVuY2luZywgYnV0IGJldHRlciBzdWl0ZWQgY29kZWNzIGV4aXN0
IGZvciB0aGF0IHVzZS1jYXNlLg0KDQpIb3dldmVyLCB3aGF0IGlzIGltcG9ydGFudCB0byBsYXkg
b3V0IGNvcnJlY3RseSBpcyB0aGUgbWFwcGluZyBvZiB0aGUgbWVkaWEgcGFyYW1ldGVycyBpbnRv
IHRoZSBhPWZtdHAgZmllbGQgb2YgU0RQLCBiZWNhdXNlIHRoaXMgaXMgYWN0dWFsbHkgdXNlZCBi
eSBtYW55IG90aGVyIHByb3RvY29scyAoc28sIGp1c3QgdGhlIG1lZGlhIGRlc2NyaXB0aW9uIHBh
cnQgb2YgU0RQIGlzIHVzZWQpLg0KDQpPcmlnaW5hbGx5LCB3ZSBiYXNlZCBvdXIgZHJhZnQgdGV4
dCBvbiBSRkMgODQ1MCAoVkMtMiBIUSBSVFAgUGF5bG9hZCkuIEluIHRoYXQgcmVzcGVjdCwgd2hh
dCBpcyB3cml0dGVuIHRoZXJlIGtpbmQgb2YgZml0cyBleGFjdGx5IHdoYXQgd2Ugd2FudCB3aXRo
IFhTLiBHaXZlbiB0aGF0IHRoaXMgaXMgYSBwdWJsaXNoZWQgUkZDLCB3ZSBhcmUgcHV6emVsZWQg
YSBiaXQgYXMgdG8gd2h5IG91ciBkcmFmdCB3b3VsZCBuZWVkIHRvIGVsYWJvcmF0ZSBzbyBleHRl
bnNpdmVseSBvbiBTRFAuIEZvciBzdXJlLCB3ZSdkIGxpa2UgdG8gYWxsb3cgU0RQIG9mZmVyL2Fu
c3dlciBuZWdvdGlhdGlvbiB3aXRoIFhTLiBCdXQgdGhpcyBpcyB2ZXJ5IHNpbXBsZTogZWFjaCBz
aWRlIHRlbGxzIHRoZSBvdGhlciBzaWRlIHdoYXQgaXQgc3VwcG9ydHMsIGFuZCB0aGF0J3MgaXQu
IEluIFhTIHRoZSBwYXJhbWV0ZXJzIGFyZSBkZWNsYXJhdGl2ZSwgbWVhbmluZyAoYXQgbGVhc3Qg
dGhhdCdzIHdoYXQgd2Ugd2FudCB0byBleHByZXNzKSB0aGF0IGVhY2ggcGFyYW1ldGVyIGlzIHJl
cHJlc2VudHMgYW4gZXhhY3QgdmFsdWUgYW5kIGlzIG5vdCAiaW5jbHVzaXZlIiBpbnRvIGEgcmFu
Z2Ugb2YgbGVzc2VyIHZhbHVlcy4gSW4gb3RoZXIgd29yZHMsIHRoZSBvdGhlciBzaWRlIGNhbm5v
dCBleHBlY3QgdGhhdCBhICJsZXNzZXIiIHZhbHVlIG9mIGEgcGFyYW1ldGVyIGNhbiB3b3JrLg0K
DQpZb3VyIHByb3Bvc2VkIHN0cnVjdHVyZSBpcyBqdXN0IHRvIGVsYWJvcmF0ZSBhbmQgb3V0IG9m
IHNjb3BlLiBBcyBzdWNoLCBJIHdvdWxkIGFzayB5b3UgdG8gY29uc2lkZXIgdGhlIGV4YW1wbGUg
b2YgUkZDIDg0NTAgKHdoZXJlIHRoZSB1c2UtY2FzZSBhbmQgcHVycG9zZSBtYXRjaGVzIHRoYXQg
b2Ygb3VyIGRyYWZ0KS4gRm9yIGV4YW1wbGU6IFdoeSBkbyB3ZSBuZWVkIHRvIHN0YXRlIGFueXRo
aW5nIHNwZWNpZmljIG9uICJNb2RpZnlpbmcgdGhlIFNlc3Npb24iPyBJc24ndCB0aGlzIGxheWVk
IG91dCBieSBTRFAgb24gaG93IHRvIG1vZGlmeSBhIHNlc3Npb24/IFRoZXJlJ3Mgbm90aGluZyBz
cGVjaWZpYyB0byBiZSBwdXQgaW4gb3VyIGRyYWZ0ICh3ZSBkbyBub3Qgd2FudCB0byBwcmV2ZW50
LCBub3Qgc3VnZ2VzdCB0aGlzIGZ1bmN0aW9uYWxpdHkpLg0KDQpJIGhvcGUgeW91IGNhbiB1bmRl
cnN0YW5kIG91ciBkaWZmaWN1bHR5IHdpdGggeW91ciByZW1hcmtzIGFuZCBjb21tZW50cy4gT3Vy
IHByb3Bvc2FsIGFzIHN1Y2ggaXMgdG8ga2VlcCB0aGUgdGV4dCBhYm91dCBTRFAgdmVyeSBzaG9y
dCBhbmQgc2ltcGxlLiBUaGUgUlRQIFBheWxvYWQgZHJhZnQgY2FuIGJlIHVzZWQgd2l0aCBTRFAs
IGJ1dCBpdCdzIGNlcnRhaW5seSBub3QgdGhlIG9ubHkgd2F5Lg0KDQpJIHdpbGwgYmUgcHJlcGFy
aW5nIGFuIHVwZGF0ZWQgZHJhZnQgd2hpY2ggdHJpZXMgdG8gYmUgdmVyeSBtaW5pbWFsIG9uIHRo
ZSBTRFAgc3BlY2lmaWNzLiBVbmxlc3MgYW55dGhpbmcgaXMgdGVjaG5pY2FsbHkgd3JvbmcsIEkg
cmVhbGx5IGhvcGUgeW91IGNhbiBhZ3JlZSB0byBpdCBhbmQgbW92ZSBmb3J3YXJkIHdpdGggdGhl
IHB1YmxpY2F0aW9uIHByb2Nlc3MuDQoNCkJlc3QgcmVnYXJkcywNClRpbS4NCg0KDQotLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogYXZ0IDxhdnQtYm91bmNlc0BpZXRmLm9yZz4gT24g
QmVoYWxmIE9mIENocmlzdGVyIEhvbG1iZXJnDQpTZW50OiBXZWRuZXNkYXkgMjYgTWF5IDIwMjEg
MTg6NDMNClRvOiBUaG9tYXMgUmljaHRlciA8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu
Y29tL3YyL3VybD91PWh0dHAtM0FfX3Rob21hcy5yaWNodGVyLTQwaWlzLmZyYXVuaG9mZXIuZGUm
ZD1Ed0lGQWcmYz1ldUdac3RjYVREbGx2aW1FTjhiN2pYcndxT2YtdjVBX0NkcGduVmZpaU1NJnI9
TFR4VUd1a0xDRWZFVWRvX2JxMDQ4USZtPWdmQjRQRi12VkJXLUhWeGNTeEN4MDdMQ2hRMUNTZXBZ
TjNKbnV2UFp2aGcmcz1XZzA4aTMyMTNiQ3lQMFliOEhqNWlocEJXai1kbHJWbktEZGpnZ09KYnFB
JmU9PjsgYXZ0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0FWVENPUkVdIFNEUCBkaXJlY3RvcmF0
ZSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1qcGVneHMtMTMNCg0KVGhpcyBpcyBh
IHN0cnVjdHVyZSB0aGF0IGlzIHR5cGljYWxseSB1c2VkIGZvciBTRFAgb2ZmZXIvYW5zd2VyIHBy
b2NlZHVyZXM6DQoNClguICBTRFAgT2ZmZXIvQW5zd2VyIFByb2NlZHVyZXMNCiAgICAgWC4xLiAg
R2VuZXJpYyBTRFAgQ29uc2lkZXJhdGlvbnMNCgk8SGVyZSB5b3UgY2FuIGRlc2NyaWJlIHRoaW5n
cyB3aGljaCBhcHBseSB0byBib3RoIG9mZmVycyBhbmQgYW5zd2Vycz4NCiAgICAgWC4yLiAgR2Vu
ZXJhdGluZyB0aGUgSW5pdGlhbCBTRFAgT2ZmZXINCgk8SGVyZSB5b3UgZGVzY3JpYmUgaG93IHRo
ZSBpbml0aWFsIFNEUCBvZmZlciBmb3IgdGhlIHNlc3Npb24gaXMgZ2VuZXJhdGVkPg0KICAgICBY
LjMuICBHZW5lcmF0aW5nIHRoZSBTRFAgQW5zd2VyDQoJPEhlcmUgeW91IGRlc2NyaWJlIGhvdyB0
aGUgYW5zd2VyZXIgZ2VuZXJhdGVzIHRoZSBTRFAgYW5zd2VyLCBpbmNsdWRpbmcgd2hldGhlciBw
YXJhbWV0ZXJzL3BhcmFtZXRlciB2YWx1ZXMgbmVlZCB0byBiZSBhIHN1YnNldCBvZiB0aGUgcGFy
YW1ldGVycy9wYXJhbWV0ZXIgdmFsdWVzIGluIHRoZSBvZmZlciBldGM+DQogICAgIFguNC4gIE9m
ZmVyZXIgUHJvY2Vzc2luZyBvZiB0aGUgU0RQIEFuc3dlcg0KICAgICA3LjUuICBNb2RpZnlpbmcg
dGhlIFNlc3Npb24NCgk8SGVyZSB5b3UgZGVzY3JpYmUgY29uc3RyYWludHMgcmVsYXRlZCB0byBt
b2RpZmljYXRpb24gb2YgdGhlIHNlc3Npb24sIGluY2x1ZGluZyB3aGV0aGVyIHRoZXJlIGFyZSBj
ZXJ0YWluIHBhcmFtZXRlcnMvcGFyYW1ldGVyIHZhbHVlcyB0aGF0IHlvdSBjYW5ub3QgbW9kaWZ5
IGV0Yz4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS0NCkZyb206IGF2dCA8YXZ0LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBDaHJpc3Rl
ciBIb2xtYmVyZw0KU2VudDoga2Vza2l2aWlra28gMjYuIHRvdWtva3V1dGEgMjAyMSAxOS4zOA0K
VG86IFRob21hcyBSaWNodGVyIDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv
dXJsP3U9aHR0cC0zQV9fdGhvbWFzLnJpY2h0ZXItNDBpaXMuZnJhdW5ob2Zlci5kZSZkPUR3SUNB
ZyZjPWV1R1pzdGNhVERsbHZpbUVOOGI3alhyd3FPZi12NUFfQ2RwZ25WZmlpTU0mcj1MVHhVR3Vr
TENFZkVVZG9fYnEwNDhRJm09THRlZlFpTGhkclh3VXljYWg3Wm1zYXlrX2R0SEYtaE1FQndIbzZE
cGV0MCZzPS1UTzFRZjdsMV9xYzRrbFJLdmJ1VzhfZUQ0TDhmODVPQjVEYWhiMkxRR0UmZT0+OyBh
dnRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQVZUQ09SRV0gU0RQIGRpcmVjdG9yYXRlIHJldmll
dyBvZiBkcmFmdC1pZXRmLXBheWxvYWQtcnRwLWpwZWd4cy0xMw0KDQpIaSwNCg0KPj4gVW5mb3J0
dW5hdGVseSBJIGRvbid0IHRoaW5rIHdoYXQgeW91IGV4cGxhaW4gYWJvdmUgaXMgdmVyeSBjbGVh
ciBpbiANCj4+IHRoZSB0ZXh0Lg0KPj4gDQo+PiBDb25zaWRlciB0aGUgZm9sbG93aW5nLg0KPj4g
DQo+PiBUaGUgb2ZmZXJlciBzZW5kcyBhbiBvZmZlci4gVGhlIG9mZmVyZXIgc3BlY2lmaWVzIHRo
ZSBjaGFyYWN0ZXJpc3RpY3MgDQo+PiB0aGF0IHRoZSBvZmZlcmVyIHdhbnRzIHRvIHJlY2VpdmUu
IFNpbWlsYXJseSwgdGhlIGFuc3dlciBzcGVjaWZpZXMgDQo+PiB0aGUgY2hhcmFjdGVyaXN0aWNz
IHRoYXQgdGhlIGFuc3dlcmVyIHdhbnRzIHRvIHJlY2VpdmUgLSB0aGUgYW5zd2VyZXIgDQo+PiBk
b2VzIE5PVCBzcGVjaWZ5IHdoYXQgaXQgaXMgZ29pbmcgdG8gc2VuZC4gd2hpY2ggSSB0aGluayB0
aGUgdGV4dCBpcyANCj4+IGN1cnJlbnRseSBkZXNjcmliaW5nLg0KPg0KPiBTb3JyeSB0byBzb3Vu
ZCBjb25mdXNlZCwgYnV0IG1heWJlIHlvdSBjb3VsZCBleHBsYWluIGEgYml0IGJldHRlci4gVG8g
bXkgdW5kZXJzdGFuZGluZywgaXQgaXMgdGhlIG9mZmVyZXIgdGhhdCBkZXNjcmliZXMgd2hhdCBp
dCBvZmZlcnMgdG8gc2VuZCwgYW5kIG5vdCB0aGUgb3RoZXIgd2F5IGFyb3VuZD8gDQo+IE1heWJl
IEkgbWlzdW5kZXJzdGFuZCBzb21ldGhpbmcgdmVyeSBmdW5kYW1lbnRhbD8gU29ycnkgdG8gYXNr
IHRoZXNlIGVsZW1lbnRhcnkgcXVlc3Rpb25zLCBidXQgdGhpcyBpcyBpbXBvcnRhbnQgZm9yIHRo
ZSB0ZXh0Lg0KDQpJbiBTRFAgT2ZmZXIvQW5zd2VyLCB0aGUgZGVmYXVsdCBpcyB0byBpbmRpY2F0
ZSB3aGF0IHlvdSBhcmUgd2lsbGluZyB0byBSRUNFSVZFIDopDQoNClR5cGljYWxseSB5b3VyIHJl
Y2VpdmluZyBjYXBhYmlsaXRpZXMgYWxzbyBpbXBsaWNpdGx5IGluZGljYXRlIHdoYXQgeW91IGFy
ZSBhYmxlIHRvIHNlbmQuIEZvciBleGFtcGxlLCBpZiBJIGFtIGluZGljYXRpbmcgdGhhdCBJIGFt
IHdpbGxpbmcgdG8gcmVjZWl2ZSBjb2RlYyBYIGl0IG5vcm1hbGx5IG1lYW5zIHRoYXQgSSBhbSBh
bHNvIGFibGUgdG8gc2VuZCBjb2RlYyBYLg0KDQogQnV0LCB0aGVyZSBhcmUgY2FzZXMgd2hlcmUg
dGhhdCBpcyBub3QgdHJ1ZSwgZXNwZWNpYWxseSB3aGVuIGl0IGNvbWVzIHRvIHZpZGVvIGNvZGVz
IHdoZXJlIHlvdSB0eXBpY2FsbHkgaGF2ZSBtb3JlIHBhcmFtZXRlcnMgYXNzb2NpYXRlZCB3aXRo
IHRoZSBjb2RlYywgYW5kIG9uZSBuZWVkcyB0byBleHBsaWNpdGx5IGluZGljYXRlIHNlbmRpbmcg
Y2FwYWJpbGl0aWVzLiANCg0KLS0tDQoNCj4+ICJUaGUgcmVjZWl2ZXIgU0hBTEwgaWdub3JlIGFu
eSB1bnJlY29nbml6ZWQgcGFyYW1ldGVyIG9yIGludmFsaWQgDQo+PiBwYXJhbWV0ZXIgdmFsdWUu
Ig0KPj4gDQo+PiBGaXJzdCwgSW4gbXkgb3BpbmlvbiBpbnZhbGlkIHBhcmFtZXRlcnMgdmFsdWVz
IHNoYWxsIHRyaWdnZXIgYW4gZXJyb3IuDQo+PiANCj4+IFNlY29uZCwgd2hhdCBpcyBhbiB1bnJl
Y29nbml6ZWQgcGFyYW1ldGVyPw0KPg0KPiBJIHdvbmRlciB3aHkgd2UgbmVlZCB0byBzcGVjaWZ5
IHRoaXMsIGkuZS4gd2hhdCBhIHJlY2VpdmUgZG9lcyBhYm91dCANCj4gcGFyYW1ldGVycyBpdCBk
b2VzIG5vdCByZWNvZ25pemU/IEVzc2VudGlhbGx5LCB0aGlzIGlzIGEgcHJvYmxlbSBvZiANCj4g
ImZvcmV3YXJkIGNvbXBhdGliaWxpdHkiLiBXb3VsZG4ndCBpdCBiZSBhIG1hdHRlciBvZiBpbXBs
ZW1lbnRhdGlvbiB3aGV0aGVyIHRoZSByZWNlaXZlciBhY2NlcHRzIGFuIG9mZmVyIChub3RlIHdl
bGwsIHRoZSByZWNlaXZlciksIGFuZCBhdHRlbXB0cyB0byBkZWNvZGUgYSBzdHJlYW0gb24gYSAi
YmVzdCBlZmZvcnQiIGJhc2lzLCBrZWVwaW5nIGluIG1pbmQgdGhhdCB0aGUgc3RyZWFtIGl0c2Vs
ZiBpbmNsdWRlcyBhZGRpdGlvbmFsIG1lYW5zIHRvIGlkZW50aWZ5IHJlcXVpcmVkIGNhcGFiaWxp
dGllcyBuZWNlc3NhcnkgZm9yIGEgc3VjY2Vzc2Z1bCBkZWNvZGUuDQo+DQo+IElmIHRoYXQgaXMg
bm90IGFuIG9wdGlvbiwgd2Ugd291bGQvY291bGQgbmVlZCBtZWFucyB0byBpZGVudGlmeSB0aGUg
DQo+IHR5cGUgb2YgcGFyYW1ldGVycyBpbiBhIGZvcmV3YXJkIGNvbXBhdGlibGUgd2F5LiBJLmUu
LCBjb252ZW50aW9ucyBieSB3aGljaCB3ZSB3b3VsZCBpZGVudGlmeSBpbiB0aGUgZnV0dXJlIHBh
cmFtZXRlcnMgYSByZWNlaXZlciBjYW4gc2FmZWx5IGlnbm9yZSBhbmQgYXR0ZW1wdCB0byBkZWNv
ZGUsIGFuZCBwYXJhbWV0ZXJzIGEgcmVjZWl2ZXIgY2Fubm90IHNhZmVseSBpZ25vcmUuDQoNCkkg
dGhpbmsgaXQgaXMgZmluZSB0byBzYXkgdGhhdCB1bnJlY29nbml6ZWQgcGFyYW1ldGVycyBzaGFs
bCBiZSBpZ25vcmVkLiBJdCBpcyB0aGVuIHVwIHRvIGZ1dHVyZSBzcGVjaWZpY2F0aW9ucyB0byB3
b3JyeSBhYm91dCBiYWNrd2FyZCBjb21wYXRpYmlsaXR5LCByYXRoZXIgdGhhbiB0aGlzIHNwZWNp
ZmljYXRpb24gd29ycnlpbmcgYWJvdXQgZm9yd2FyZCBjb21wYXRpYmlsaXR5Lg0KDQo+PiBBbHNv
LCB0aGUgdGV4dCBkb2VzIG5vdCBzYXkgd2hhdCByZXN0cmljdGlvbnMgKGlmIGFueSkgdGhlcmUg
YXJlIHdoZW4gDQo+PiBpdCBjb21lcyB0byBtb2RpZnkgdGhlIHN0cmVhbSBkdXJpbmcgYSBzZXNz
aW9uLiBJcyBpdCBhbGxvd2VkIHRvIA0KPj4gbW9kaWZ5IGFueS9hbGwgY2hhcmFjdGVyaXN0aWNz
Pw0KPg0KPiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgeW91IGNhbm5vdCBtb2RpZnkgY2hhcmFj
dGVyaXN0aWNzIGR1cmluZyBhIA0KPiBzZXNzaW9uLiBJZiB5b3UgbmVlZCB0byBtb2RpZnksIHlv
dSBuZWVkIHRvIHNldHVwIGEgbmV3IHNlc3Npb24gYW5kIA0KPiBjYW5jZWwgdGhlIGN1cnJlbnQg
b25lLiBGb3IgSlBFRyBYUyBzdHJlYW0gZGVjb2RlcnMsIG9uZSBjYW5ub3QgZXhwZWN0IHRoYXQg
YW4gaW5zdGFuY2lhdGVkIGRlY29kZXIgY2FuIGRlY29kZSBmcm9tIG1vZGlmaWVkIHBhcmFtZXRl
cnMgaW4gbWlkLXN0cmVhbSBsZXZlbC4gVGhhdCBpcywgaWYgeW91IHN0YXJ0IGRlY29kaW5nIGlu
IGZ1bGwtSEQsIGFuZCB0aGVuIHN0cmVhbSBwYXJhbWV0ZXJzIGJlY29tZSA4SywgdGhlIGRlY29k
ZXIgd2lsbCBoYXZlIHRvIGFib3J0Lg0KDQpUaGVzZSBraW5kIG9mIHRoaW5ncyBuZWVkIHRvIGJl
IHNwZWNpZmllZC4gSSBkb24ndCB0aGluayBpdCBuZWVkcyB0byBiZSBmb3JiaWRkZW4gdG8gdHJ5
IHRvIG1vZGlmeSBzb21ldGhpbmcsIGJlY2F1c2UgdGhlcmUgY291bGQgYmUgdGV4dCB0aGF0IHN0
cm9uZ2x5IHJlY29tbWVuZHMgYWdhaW5zdCBkb2luZyBpdC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0
ZXINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkF1
ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQphdnRAaWV0Zi5vcmcNCmh0dHBz
Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYu
b3JnX21haWxtYW5fbGlzdGluZm9fYXZ0JmQ9RHdJQ0FnJmM9ZXVHWnN0Y2FURGxsdmltRU44Yjdq
WHJ3cU9mLXY1QV9DZHBnblZmaWlNTSZyPUxUeFVHdWtMQ0VmRVVkb19icTA0OFEmbT1MdGVmUWlM
aGRyWHdVeWNhaDdabXNheWtfZHRIRi1oTUVCd0hvNkRwZXQwJnM9MXZaVHVGakktUWJleFA1b1g5
cGdhMzVkWlp6dGhYR2duN1M4WmdvZDlMRSZlPQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRl
bmFuY2UNCmF2dEBpZXRmLm9yZw0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy
L3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19hdnQmZD1Ed0lD
QWcmYz1ldUdac3RjYVREbGx2aW1FTjhiN2pYcndxT2YtdjVBX0NkcGduVmZpaU1NJnI9TFR4VUd1
a0xDRWZFVWRvX2JxMDQ4USZtPUx0ZWZRaUxoZHJYd1V5Y2FoN1ptc2F5a19kdEhGLWhNRUJ3SG82
RHBldDAmcz0xdlpUdUZqSS1RYmV4UDVvWDlwZ2EzNWRaWnp0aFhHZ243UzhaZ29kOUxFJmU9DQpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQXVkaW8vVmlk
ZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UNCmF2dEBpZXRmLm9yZw0KaHR0cHM6Ly91cmxk
ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFp
bG1hbl9saXN0aW5mb19hdnQmZD1Ed0lHYVEmYz1ldUdac3RjYVREbGx2aW1FTjhiN2pYcndxT2Yt
djVBX0NkcGduVmZpaU1NJnI9TFR4VUd1a0xDRWZFVWRvX2JxMDQ4USZtPVZ2c2E3dUZBNXowRFdu
QlNvTkVudmFfNGlqNXJiY1FHT3dMcF9pLTN6N3cmcz1vaUwycGRsN2hfNkxWWS00RTg4aFZWSTFO
b0RXczZqQk9MYjFyV3JBX25JJmU9DQo=


From nobody Mon May 31 07:42:28 2021
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00623A1A7D for ; Mon, 31 May 2021 07:42:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.886
X-Spam-Level: 
X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=intopix.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nG9F2X-hrLt9 for ; Mon, 31 May 2021 07:42:20 -0700 (PDT)
Received: from dispatchb-eu1.ppe-hosted.com (dispatchb-eu1.ppe-hosted.com [185.183.29.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F16003A1A7C for ; Mon, 31 May 2021 07:42:19 -0700 (PDT)
X-Virus-Scanned: Proofpoint Essentials engine
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp2053.outbound.protection.outlook.com [104.47.1.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1-eu1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 0DEC37C0061; Mon, 31 May 2021 14:42:16 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XTVIq1AccooOl9IsWYo0FHEL8ValIPhlYUYcvbSgza4FNqnhHZ2bOcF4YFUWxLC70iVPW5lhEbsY7SIq5f80NC4A1Wq5oVoUDjbbobgx6EHDn10cZWktCS2wDuvb7vMd0AgElhC/fXFHQV0cufBCzr1ZWePGETRQDDvvCIN1G1P/18mU+Pql31ce/TvxCA/xmizwGyV9VjhkgnlztLHgTfCG3md/W/mGuEyL22pLJfr0gWPhifHbm88u6z2GHBj3pQPqiA3XKebUlNgbpijzlv9dJMHXveCVXlWpfA+qS9Wbzd1YUFXfBmIq1cmziKUEIDGG17p46pHKQaDuK4Wr8A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rDLGJXqsf+LQb+V7UnMRiKRqerG3xNMBd2dmeZjgqGI=; b=cGdZSAqf/7vQEHLbjuhHdAGLH8grkbCfmYupadZ3qaLYIJ0uih3pkSMA5ikzxIjM1m+AD3MZqaFp/o+ZSRowDB54IqeB4YCGm2w4lTnmuP2KAlrp8iIBsPTuM6xsel3hTynKq2n+unNoALnKjGjpG+WKXsFlstXw6VwHb2XZNbwpccZCHaxZ4THMEdLKr06xUSljXaBLBqCItkVEJ0PydWIGU9qBTv8aUVoBZKp+bOarVhFMimD727WZEFLTtO5GEKwNww4B6N9YhvsayjCMfQe75lS5T/x5VPOr5ndj9HcOKtpyCRYI+eY0ceXGqHD/MDwHJfPRp2pVxwLig4i/gA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intopix.com; dmarc=pass action=none header.from=intopix.com; dkim=pass header.d=intopix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intopix.onmicrosoft.com; s=selector1-intopix-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rDLGJXqsf+LQb+V7UnMRiKRqerG3xNMBd2dmeZjgqGI=; b=eIG0dvaYYucsroex2DxGBGbohct0t8MySQnQVX3xnGu+1rAtGTncBEZJ8cLi0dHWamnT0vKzCH7W/uqsANfrNq9HcJRnClVf/TSvJppHsi2kHkri0rqsFiPkuRabmnTpSE+9/j3eTiQOIg4l+M0qPxeaDNjOhJZxeSbvrFqHDBo=
Received: from PR3P192MB0748.EURP192.PROD.OUTLOOK.COM (2603:10a6:102:4f::24) by PAXP192MB1198.EURP192.PROD.OUTLOOK.COM (2603:10a6:102:1af::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.21; Mon, 31 May 2021 14:42:15 +0000
Received: from PR3P192MB0748.EURP192.PROD.OUTLOOK.COM ([fe80::8ab:c06a:c2cf:b0ac]) by PR3P192MB0748.EURP192.PROD.OUTLOOK.COM ([fe80::8ab:c06a:c2cf:b0ac%9]) with mapi id 15.20.4173.030; Mon, 31 May 2021 14:42:15 +0000
From: Tim Bruylants 
To: Christer Holmberg , Thomas Richter , "avt@ietf.org" 
CC: Jean-Baptiste Lorent 
Thread-Topic: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
Thread-Index: AddLKBOH9HzaEV4jTtmQ8TPYzmKsqwFVwo+gABfRKwAAFpWSgABEymJQAABwR+AAT0NxwAAES3xQAAEQhVAAkqc4oAAOiNkwAACTaHA=
Date: Mon, 31 May 2021 14:42:14 +0000
Message-ID: 
References:    <7aa5e890-47c5-cdb7-5657-26864cec3d4c@iis.fraunhofer.de>       
In-Reply-To: 
Accept-Language: en-US, nl-NL
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=intopix.com;
x-originating-ip: [94.227.86.241]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b4aea6a9-5023-4f31-feb9-08d92442486d
x-ms-traffictypediagnostic: PAXP192MB1198:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: EbvGhfrxl+h0ZjVxDWwuCWWAVZf/BnigmtXp6JuxkjTc0w/U+fakQUL9juL2R8uPT736QkzfUieyt40dQkrTwFGlw68aqzs7fNTzlhPanNOzHpeKQPDd5uck63i/et0JmXHZw2IKaGykNwrUnVBTmEnd2j3QUBlR05UtrdR65+yL94dCAQrmRx6GvINGkfvT0wiRLJ9tOx8Opclbidntwn3oe6tlM9OHTjXn06uwRW2kFPWq86KfF9fQnrAy7FTmj2XJEuLXK2EYJypG4bDyCOmp4A8X6P8Yaww3AvIJVkd1g+TB7wVv7J74/1kZRVdlMabj/eEDaSpn7t0TWb+A6mpiEggGfivzzgrxZ4H9EHoqtEVjJdulH/zBIUhjrx29x5vAONRLPEoB7qIeHcbqtxwKTxGg2YyVPOZ9I/Uh0KD5+UeJ1TQBaB24XmlLkZ9WJBij0aPUYqsiO/4UrQhKFoAcsjhvm2M2XVbXp6nqpEKLkb4B2G7oV+HMtQJ2+m93INhpq+ykMgyFtZml4exyHzBIIQODEB1tjL1QP68+wbU3YmVAa+cSgqU4DPXde4X/bStWXbCNNF0XEyagu18d3nwLQPzkNGg5zOUvnhjKsf/JbTaev8WHiV13hUHfL4LEvxwDAhI4clnIIgFwpv+tP4pdOQymbuqttuuVfZ7pNzyAIZSqQpZS/ytAV+C3lB2a6NPXjy6ecv1JYhdh1bPutxiqiTRd64Otf7xYJtU8Wtg=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:PR3P192MB0748.EURP192.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFS:(366004)(376002)(346002)(39830400003)(136003)(396003)(4326008)(83380400001)(55016002)(33656002)(478600001)(66946007)(966005)(71200400001)(2906002)(107886003)(122000001)(186003)(316002)(38100700002)(9686003)(5660300002)(76116006)(7696005)(26005)(110136005)(8936002)(86362001)(66556008)(66446008)(64756008)(66476007)(8676002)(52536014)(6506007)(30864003)(53546011); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?utf-8?B?N0p3amFMdWtDaTVwUEIyV001ZnA3bFZ2Nk9TSWd1RzZCUUplYjlmZzNHSGhu?= =?utf-8?B?cWs3T3ZKN2taYU9pNno4dEJNUHl3U1JzWEs0a2dMV0RlMDlKT2Z3NVFQVXhi?= =?utf-8?B?UTRMdnJDb2EzQ1V3L1kyam1ERDY3SnR4ZWRpejFGU0NHZDQ3UHZIL1M4MEFE?= =?utf-8?B?c0dMV3lIZ2Z6bWtlMkxkUTVkeitTenNaczZBY002WlNkSHFBbGdYTkVDRnFx?= =?utf-8?B?UFhQU1NvbFliR01YWS9sMlhPN0wyZjZaQkhibjFzVE5ZeXRBS0FCRk9FeitB?= =?utf-8?B?ZE9KR1d4dWJvN1dsSlZqYmxYUldBRU8wTkdodUp2UUtpd2hoenhVdDFLSXZN?= =?utf-8?B?b3JwajRlY2ZVcmN2cUV6OS9ZUXhSUmlhM2xSWWNoV0FxempNNDlqNWJxZnlX?= =?utf-8?B?ZlJYZ1ZkZVlYb1VFV0c1Lzg4NG81SjR6MklEbEZOZGhSa0IvL2lBSkJMMUxk?= =?utf-8?B?VVlIYlArY3Q3d3FEUHNRYkNDdElWS3ovc0JYSEdiUnpQQ2pvWmcwVHBPdTFT?= =?utf-8?B?VFBaRTZ5K0NDVEZUeG5GZ01FTCtzNTJVU2F1MnNrNkNUYmJiQmpab2wyaHlU?= =?utf-8?B?RCtqQTV0ZG9rR3dQQ2ZaR21TQzRyZGkyNkFQSGoyRXp6RFkyNlBZUkdGOUUy?= =?utf-8?B?a2J0S0ZvNnBvYkJ2Q2dQYTZmUW0vMTUvNnlvSWh6M0dYVUk3VWcrenVRKzgw?= =?utf-8?B?Qi9ldmFLaCtyenk1NHRSOEdUbnBCOFI1VU5YSHljenE4d2ZZcnA3TVFwWEFo?= =?utf-8?B?S1U1RHBqWHVGcHhaZ0JtUXAxK0cvU21FK0k5RXMzRTJaejREZXp5ZzRwZWxM?= =?utf-8?B?enJNQWx3bVVJUUlseTNhZ3QrOHNvRGlTODJoMmRPRTVqYkFvMHd1UUNlaVh1?= =?utf-8?B?eVAybzRGc1VQYVRKUVZrYUhLTk1oU0pTU1k0YWR1Mm5YNGdlaGgxckMxZHc4?= =?utf-8?B?ZFNWWk9FZ0ZBYzFxeTNCeHN3R1JPcUd6aXFpSXpuMUhvSUZTQWxkYVRUNFlR?= =?utf-8?B?UFNxdXJXcjIxdW9PeHMxWnYxRDF0Z1ExcE5OZXVqTy9UeFZjL2Q1K2NzWmpr?= =?utf-8?B?NFVEcXF0cWpWWi9LY1JUVjhrYzNCbG1YWWFzN2lIMjhRL2xLQldlbFYxWktR?= =?utf-8?B?OEd5Q3o0YVc2N1R0b0x6UHpZd052YlhnVTd4N28yb0hTMW5PbmNKNlBXQjJ4?= =?utf-8?B?UVlkOERhWXNaVEJNdG5EekNtQ3ZWOFJKZ2llV2RaelpOejdXS1VrZXA0Nms0?= =?utf-8?B?YXFuMi9WRnk1dDhDZ2lvTUxYUlV4OU1ld1BXdzdpSGFNNzcyZThaOVNVYkNC?= =?utf-8?B?TkwwSnhSSWIzWnE2aGx3WUJja00xcnJJN2RzQ0kvTFBUQkdPSUQ3YWhFVjNi?= =?utf-8?B?UU9mSU9DdTFBWjhid2FNYktYRGJVMWZRTzNiV2F2VCtCOXVNVWxxUEQxL1Y3?= =?utf-8?B?QjU4R01MTkdJRFRaa2V6MUtndmVkUkc1dlN0TUZYV09ubXNKOU93ZFk3Qjl4?= =?utf-8?B?ZzdESWtHMEFZRUdsYWdGbUlBU29zTXdURWNEMUFXVjRvMkg2dHcrekxBdHJF?= =?utf-8?B?dVZmaVdodVl4aE8ra3ZvNzQ2Z3BmRmc5MVZQQjdBanlvaURNdDIvVFZVM1R0?= =?utf-8?B?M1JDTlFEbkNRdHB3eURrUmhQOFhRK1ovZTYxYWRCK29mdWZSampqV2JMYkJG?= =?utf-8?B?VlhKbTVpc3U5OVRNZkk4L2NHeG5OOGhFbWVRUlZUbU9MME1KOWljbjlEQk1P?= =?utf-8?Q?10xQjD97Hc5NQ68a1j/Z86y2AkcxpWdYu5cLQmB?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: intopix.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PR3P192MB0748.EURP192.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: b4aea6a9-5023-4f31-feb9-08d92442486d
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2021 14:42:15.0319 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5f9168c7-cdac-4b23-9509-c278399e3c1f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: kEXCz7WG3x3Ohsgk/zUfzt3Yj85HfFVPLAzYHOynUW/N88SZYG2o70GaLxKPzAHQ
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXP192MB1198
X-MDID: 1622472137-6umH550fjmkj
Archived-At: 
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 May 2021 14:42:27 -0000

SGkgQ2hyaXN0ZXIsDQoNCjEpIFlvdSBhcmUgY29ycmVjdCB0aGF0IHRoZSBwYXJhbWV0ZXJzIGFy
ZSBkZXNjcmliaW5nIHdoYXQgdGhlIHNlbmRlciB3aWxsIGJlIHVzaW5nIGluIHRoZSBwYXlsb2Fk
IChzdHJpY3RseSBzcGVha2luZyB0aGVzZSBhcmUgbm90IGNhcGFiaWxpdGllcywgYnV0IHJhdGhl
ciBzdHJpY3QgcGF5bG9hZCBzZXR0aW5ncyB0aGF0IHdpbGwgYmUgaG9ub3JlZCkuIFRoZSByZWNl
aXZlciBzaG91bGQgYmUgYWJsZSB0byBoYW5kbGUgc3VjaCBzZXR0aW5ncyAoYXMgZGVzY3JpYmVk
IGJ5IHRoZXNlIHBhcmFtZXRlcnMpLg0KSSB3aWxsIGFkanVzdCB0aGF0IHBhcnQgdG8gcmVmbGVj
dCB3aGF0IHlvdSBwcm9wb3NlLg0KDQoyKSBJIHdpbGwgaW5kZWVkIHJlcGxhY2UgY3JlYXRvci9y
ZWNlaXZlciBieSBvZmZlcm9yL2Fuc3dlcmVyIHJlc3BlY3RpdmVseS4gQXMgZm9yIHRoZSBhbnN3
ZXJlcjogb24gYWNjZXB0aW5nIHRoZSBjb25uZWN0aW9uIHdpdGggdGhlIG9mZmVyZWQgcGFyYW1l
dGVycywgdGhlcmUgaXMgbm90IG11Y2ggdG8gc2VuZCBiYWNrIHcuci50LiBwYXJhbWV0ZXJzLiBC
dXQgZm9yIGVhc3kgb2YgcmVjb2duaXppbmcgdGhlIG5lZ290aWF0ZWQgc3RyZWFtLCB3ZSBiZWxp
ZXZlIHRoZSBhbnN3ZXJlciBzaG91bGQgdXNlIHRoZSBzYW1lIGZtdHAgKGFzIGdpdmVuIGluIHRo
ZSBvZmZlcikgaW4gaXRzIGFuc3dlci4NCg0KU28sIHVwZGF0ZWQgdGV4dCB3b3VsZCBiZWNvbWU6
DQoNCi8vLS0tIFNOSVBQRVQNCjguMi4gIFVzYWdlIHdpdGggU0RQIE9mZmVyL0Fuc3dlciBNb2Rl
bA0KDQogICBXaGVuIEpQRUcgWFMgaXMgb2ZmZXJlZCBvdmVyIFJUUCB1c2luZyBTRFAgaW4gYW4g
b2ZmZXIvYW5zd2VyIG1vZGVsDQogICBbUkZDMzI2NF0gZm9yIG5lZ290aWF0aW9uIGZvciB1bmlj
YXN0IHVzYWdlLCB0aGUgZm9sbG93aW5nDQogICBsaW1pdGF0aW9ucyBhbmQgcnVsZXMgYXBwbHk6
DQoNCiAgICAgIFRoZSAiYT1mbXRwIiBhdHRyaWJ1dGUgU0hBTEwgYmUgcHJlc2VudCBzcGVjaWZ5
aW5nIHRoZSByZXF1aXJlZA0KICAgICAgcGFyYW1ldGVyICJ0cmFuc21vZGUiIGFuZCBNQVkgc3Bl
Y2lmeSBhbnkgb2YgdGhlIG9wdGlvbmFsDQogICAgICBwYXJhbWV0ZXJzLCBhcyBkZXNjcmliZWQg
aW4gU2VjdGlvbiA3LjEuDQoNCiAgICAgIEFsbCBwYXJhbWV0ZXJzIGluIHRoZSAiYT1mbXRwIiBh
dHRyaWJ1dGUgaW5kaWNhdGUgc2VuZGluZw0KICAgICAgY2FwYWJpbGl0aWVzIChpLmUuIHByb3Bl
cnRpZXMgb2YgdGhlIHBheWxvYWQpLg0KDQogICAgICBBbiBhbnN3ZXJlciBvZiB0aGUgU0RQIGlz
IHJlcXVpcmVkIHRvIHN1cHBvcnQgYWxsIHBhcmFtZXRlcnMgYW5kDQogICAgICB2YWx1ZXMgb2Yg
dGhlIHBhcmFtZXRlcnMgcHJvdmlkZWQgYnkgdGhlIG9mZmVyb3I7IG90aGVyd2lzZSwgdGhlDQog
ICAgICBhbnN3ZXJlciBTSEFMTCByZWplY3QgdGhlIHNlc3Npb24uICBJdCBmYWxscyBvbiB0aGUg
b2ZmZXJvciBvZiB0aGUNCiAgICAgIHNlc3Npb24gdG8gdXNlIHZhbHVlcyB0aGF0IGFyZSBleHBl
Y3RlZCB0byBiZSBzdXBwb3J0ZWQgYnkgdGhlDQogICAgICBhbnN3ZXJpbmcgYXBwbGljYXRpb24u
ICBJZiB0aGUgYW5zd2VyZXIgYWNjZXB0cyB0aGUgc2Vzc2lvbiwgaXQNCiAgICAgIFNIQUxMIHJl
cGx5IHdpdGggdGhlIGV4YWN0IHNhbWUgcGFyYW1ldGVycyBpbiB0aGUgImE9Zm10cCINCiAgICAg
IGF0dHJpYnV0ZSBhcyBpdCB3YXMgb2ZmZXJlZC4NCi8vLS0tIFNOSVBQRVQNCg0KDQpJZiB5b3Ug
YmVsaWV2ZSB0aGlzIGlzIG9rLCBJIHdpbGwgcG9zdCBhbiB1cGRhdGVkIGRyYWZ0IHRvIHRoZSBk
YXRhdHJhY2tlci4NCg0KQmVzdCByZWdhcmRzLA0KVGltLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz
c2FnZS0tLS0tDQpGcm9tOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp
Y3Nzb24uY29tPiANClNlbnQ6IE1vbmRheSAzMSBNYXkgMjAyMSAxNjoxMA0KVG86IFRpbSBCcnV5
bGFudHMgPFRCUkBpbnRvcGl4LmNvbT47IFRob21hcyBSaWNodGVyIDx0aG9tYXMucmljaHRlckBp
aXMuZnJhdW5ob2Zlci5kZT47IGF2dEBpZXRmLm9yZw0KQ2M6IEplYW4tQmFwdGlzdGUgTG9yZW50
IDxqYi5sb3JlbnRAaW50b3BpeC5jb20+DQpTdWJqZWN0OiBSRTogW0FWVENPUkVdIFNEUCBkaXJl
Y3RvcmF0ZSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1qcGVneHMtMTMNCg0KSGkg
VGltLA0KDQo+QmVmb3JlIEkgdXBsb2FkIGEgbmV3IGRyYWZ0IHRvIGFkZHJlc3MgdGhlIFNEUCwg
SSB3b3VsZCBsaWtlIHlvdSB0byByZXZpc2UgdGhlIGZvbGxvd2luZyB0ZXh0Lg0KPg0KPkFzIHlv
dSBzdGF0ZWQsIHdoZW4gZGVzY3JpYmluZyB0aGUgU0RQIG9mZmVyL2Fuc3dlciBtb2RlbCwgdGhl
IGRyYWZ0IG5lZWRzIHRvIGFkZHJlc3MgdGhlIDUgZm9sbG93aW5nIHRvcGljczoNCj5YLjEgR2Vu
ZXJpYyBTRFAgQ29uc2lkZXJhdGlvbnMNCj5YLjIuICBHZW5lcmF0aW5nIHRoZSBJbml0aWFsIFNE
UCBPZmZlcg0KPlguMy4gIEdlbmVyYXRpbmcgdGhlIFNEUCBBbnN3ZXINCj5YLjQuICBPZmZlcmVy
IFByb2Nlc3Npbmcgb2YgdGhlIFNEUCBBbnN3ZXIgWC41LiAgTW9kaWZ5aW5nIHRoZSBTZXNzaW9u
DQo+DQo+T3VyIHF1ZXN0aW9uOiBJcyB0aGlzIHN1ZmZpY2llbnRseSBkZXNjcmliZWQgaW4gUkZD
MzI2NCBhbmQgaXMgaXQgb2sgdG8gcmVmZXIgdG8gdGhhdCBSRkMgd2l0aCBzb21lIGV4dHJhIGNs
YXJpZmljYXRpb25zPyBSRkMzMjY0IHNlZW1zIHRvIGJlIHdoYXQgd2UgaW50ZW5kICJpZiIgc2Rw
IG9mZmVyL2Fuc3dlciBpcyB1c2VkLiBUaGlzIHdvdWxkIHJlc3VsdCBpbiB0aGUgZm9sbG93aW5n
IHRleHQ6DQo+DQo+Ly8tLS0gU05JUFBFVA0KPjguMi4gIFVzYWdlIHdpdGggU0RQIE9mZmVyL0Fu
c3dlciBNb2RlbA0KPg0KPiAgIFdoZW4gSlBFRyBYUyBpcyBvZmZlcmVkIG92ZXIgUlRQIHVzaW5n
IFNEUCBpbiBhbiBvZmZlci9hbnN3ZXIgbW9kZWwNCj4gICBbUkZDMzI2NF0gZm9yIG5lZ290aWF0
aW9uIGZvciB1bmljYXN0IHVzYWdlLCB0aGUgZm9sbG93aW5nDQo+ICAgbGltaXRhdGlvbnMgYW5k
IHJ1bGVzIGFwcGx5Og0KPg0KPiAgICAgIFRoZSAiYT1mbXRwIiBhdHRyaWJ1dGUgU0hBTEwgYmUg
cHJlc2VudCBzcGVjaWZ5aW5nIHRoZSByZXF1aXJlZA0KPiAgICAgIHBhcmFtZXRlciAidHJhbnNt
b2RlIiBhbmQgTUFZIHNwZWNpZnkgYW55IG9mIHRoZQ0KPiAgICAgIG9wdGlvbmFsIHBhcmFtZXRl
cnMsIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDcuMS4NCj4NCj4gICAgICBBbGwgcGF5bG9hZCBw
YXJhbWV0ZXJzIGFyZSBkZWNsYXJhdGl2ZSwgbWVhbmluZyB0aGF0IHRoZXkgZGVzY3JpYmUNCj4g
ICAgICBwcm9wZXJ0aWVzIG9mIHRoZSBwYXlsb2FkLg0KPg0KPiAgICAgIEEgcmVjZWl2ZXIgb2Yg
dGhlIFNEUCBpcyByZXF1aXJlZCB0byBzdXBwb3J0IGFsbCBwYXJhbWV0ZXJzIGFuZA0KPiAgICAg
IHZhbHVlcyBvZiB0aGUgcGFyYW1ldGVycyBwcm92aWRlZDsgb3RoZXJ3aXNlLCB0aGUgcmVjZWl2
ZXIgU0hBTEwNCj4gICAgICByZWplY3QgdGhlIHNlc3Npb24uICBJdCBmYWxscyBvbiB0aGUgY3Jl
YXRvciBvZiB0aGUgc2Vzc2lvbiB0byB1c2UNCj4gICAgICB2YWx1ZXMgdGhhdCBhcmUgZXhwZWN0
ZWQgdG8gYmUgc3VwcG9ydGVkIGJ5IHRoZSByZWNlaXZpbmcNCj4gICAgICBhcHBsaWNhdGlvbi4N
Cj4vLy0tLSBTTklQUEVUDQo+DQo+IEZlZWRiYWNrIHdvdWxkIGJlIHZlcnkgd2VsY29tZS4NCg0K
QSBjb3VwbGUgb2YgY29tbWVudHM6DQoNCg0KUTE6DQoNCiJBbGwgcGF5bG9hZCBwYXJhbWV0ZXJz
IGFyZSBkZWNsYXJhdGl2ZSwgbWVhbmluZyB0aGF0IHRoZXkgZGVzY3JpYmUgcHJvcGVydGllcyBv
ZiB0aGUgcGF5bG9hZC4iDQoNCkkgZG9uJ3QgdGhpbmsgeW91IG5lZWQgdG8gc2F5IHRoYXQuDQoN
CkJhc2VkIG9uIG91ciBlYXJsaWVyIGRpc2N1c3Npb25zLCBJIHRoaW5rIHdoYXQgeW91IG5lZWQg
dG8gcG9pbnQgb3V0IGlzIHRoYXQgdGhlIGZtdHAgYXR0cmlidXRlIGlzIHVzZWQgdG8gaW5kaWNh
dGUgU0VORElORyBjYXBhYmlsaXRpZXMuDQoNCi0tLS0NCg0KUTI6DQoNCiJBIHJlY2VpdmVyIG9m
IHRoZSBTRFAgaXMgcmVxdWlyZWQgdG8gc3VwcG9ydCBhbGwgcGFyYW1ldGVycyBhbmQgdmFsdWVz
IG9mIHRoZSBwYXJhbWV0ZXJzIHByb3ZpZGVkOyBvdGhlcndpc2UsIHRoZSByZWNlaXZlciBTSEFM
TCByZWplY3QgdGhlIHNlc3Npb24uICBJdCBmYWxscyBvbiB0aGUgY3JlYXRvciBvZiB0aGUgc2Vz
c2lvbiB0byB1c2UgdmFsdWVzIHRoYXQgYXJlIGV4cGVjdGVkIHRvIGJlIHN1cHBvcnRlZCBieSB0
aGUgcmVjZWl2aW5nIGFwcGxpY2F0aW9uLiINCg0KSW5zdGVhZCBvZiAicmVjZWl2ZXIiLCBJIHdv
dWxkIHNheSBhbnN3ZXJlci4NCg0KSW5zdGVhZCBvZiAiY3JlYXRvciIsIEkgd291bGQgc2F5IG9m
ZmVyZXIuDQoNCkFsc28sIGFzc3VtaW5nIHRoZSBhbnN3ZXJlci9yZWNlaXZlciBhY2NlcHRzIHRo
ZSBvZmZlciwgdGhlcmUgaXMgbm8gdGV4dCBvbiB3aGF0IGl0IGluY2x1ZGVzIGluIHRoZSBhbnN3
ZXIuIERvZXMgdGhlIGFuc3dlcmVyIGFsc28gaW5jbHVkZSBhbiBmbXRwIGF0dHJpYnV0ZT8gSWYg
c28sIHdoYXQgdmFsdWVzIGRvZXMgaXQgaW5jbHVkZT8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXIN
Cg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGF2dCA8YXZ0LWJvdW5j
ZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBUaW0gQnJ1eWxhbnRzDQpTZW50OiBGcmlkYXkgMjgg
TWF5IDIwMjEgMTI6MjENClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdA
ZXJpY3Nzb24uY29tPjsgVGhvbWFzIFJpY2h0ZXIgPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv
aW50LmNvbS92Mi91cmw/dT1odHRwLTNBX190aG9tYXMucmljaHRlci00MGlpcy5mcmF1bmhvZmVy
LmRlJmQ9RHdJR2FRJmM9ZXVHWnN0Y2FURGxsdmltRU44YjdqWHJ3cU9mLXY1QV9DZHBnblZmaWlN
TSZyPUxUeFVHdWtMQ0VmRVVkb19icTA0OFEmbT1QdklLbm95MklSTVJfWnlqUUdEZlhvRkF1WlpK
VnUyTEVhMzdDSEdsaUcwJnM9Z0xfOTFod3cyQ3RmaFNDYVFyYkpUdWJVTzFLZWNqTnRGRl93OVdP
UkQ1ZyZlPT47IGF2dEBpZXRmLm9yZw0KQ2M6IEplYW4tQmFwdGlzdGUgTG9yZW50IDxqYi5sb3Jl
bnRAaW50b3BpeC5jb20+DQpTdWJqZWN0OiBSZTogW0FWVENPUkVdIFNEUCBkaXJlY3RvcmF0ZSBy
ZXZpZXcgb2YgZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1qcGVneHMtMTMNCg0KSGkgQ2hyaXN0ZXIs
DQoNClRoYW5rcyBmb3IgdGhlIHF1aWNrIHJlc3BvbnNlLCB3ZSByZWFsbHkgYXBwcmVjaWF0ZSB5
b3VyIHRpbWUuDQoNClNvLCBsZXQgbWUgZWxhYm9yYXRlIGEgYml0Og0KDQo+PiBGaXJzdCwgcmVn
YXJkaW5nIFJGQyA4NDUwLCB0aGF0IHNwZWNpZmljYXRpb24gd2FzIHByb2JhYmx5IG5ldmVyIHJl
dmlld2VkIGJ5IHRoZSBTRFAgZGlyZWN0b3JhdGUsIHNvIEkgY2FuJ3QgcmVhbGx5IGNvbW1lbnQg
b24gdGhhdC4gQnV0LCBJIHNlZSB0aGF0IHRoZSBSRkMgZS5nLiwgc2F5cyBub3RoaW5nIGFib3V0
IHdoZXRoZXIgdGhlIFNEUCBpbmRpY2F0ZXMgc2VuZGluZyBvciByZWNlaXZpbmcgY2FwYWJpbGl0
aWVzLg0KDQpPaywgSSB1bmRlcnN0YW5kIHRoYXQgUkZDIDg0NTAgbWlnaHQgbm90IGJlIGVudGly
ZWx5IGNsZWFyIG9yIHdlbGwgd3JpdHRlbiBvbiB0aGUgU0RQIHBhcnQuDQoNCj4+IFNlY29uZCwg
bm9ib2R5IG1hbmRhdGVzIHlvdSB0byB1c2UgU0RQLCBhbmQgbW9zdCBwYXJ0IG9mIHRoZSBzcGVj
IGlzIHByb3RvY29sIGluZGVwZW5kZW50LiBCdXQsIHRoZSAiU0RQIE9mZmVyL0Fuc3dlciIgc2Vj
dGlvbiBkZXNjcmliZXMgdGhlIFNEUCBvZmZlci9hbnN3ZXIgcHJvY2VkdXJlcywgKklGKiB5b3Ug
Y2hvb3NlIHRvIHVzZSB0aGF0IG1lY2hhbmlzbSBmb3IgbmVnb3RpYXRpbmcgdGhlIHNlc3Npb24u
DQoNCk9rLiBUaGF0IEkgdW5kZXJzdGFuZC4gSW4gb3VyIGNhc2UsIFNEUCBhcyB0aGUgc2Vzc2lv
biBwcm90b2NvbCBpcyBub3QgY3JpdGljYWwsIGJ1dCBzdGlsbCBhIG5pY2UgdG8gaGF2ZS4gRG8g
eW91IGFncmVlPyBPciBkbyB5b3UgcmVjb21tZW5kIHdlIHJlbW92ZSB0aGUgU0RQIG9mZmVyL2Fu
c3dlciBzZWN0aW9uPw0KDQpXaGF0IHdlIGRvIG5lZWQgdG8gc2F5IGlzIGhvdyB0byBtYXAgcGFy
YW1ldGVycyBpbnRvIGFuIFNEUC1jb21wbGlhbnQgZm9ybWF0IGRlc2NyaXB0aW9uLCBmb3IgdGhl
IHNhbWUgcmVhc29ucyBhcyBSRkMgODQ1MCBhbmQgbWFueSBvdGhlciB2aWRlbyBwYXlsb2FkIFJG
QydzIChWUDgsIFZQOSwgSC4yNjQvQVZDLCBILjI2NS9IRVZDLCBldGMpLiBUaGlzIGFsbG93cyB1
c2luZyBtYW55IG90aGVyIHNlc3Npb24gbmVnb3RpYXRpb24gcHJvdG9jb2xzIHRoYXQgcmVseSBv
biB0aGUgU0RQIGRlc2NyaXB0aW9uLg0KDQo+PiBUaGlyZCAuLi4uDQoNCkkgYmVsaWV2ZSB3aGF0
IGlzIHZlcnkgaW1wb3J0YW50IHRvIGV4cGxhaW4gaXMgdGhhdCBhbGwgb2Ygb3VyIHBhcmFtZXRl
cnMgYXJlIGRlY2xhcmF0aXZlLCBtZWFuaW5nIHRoYXQgdGhleSBkZXNjcmliZSBleGFjdCBiaXRz
dHJlYW0gcHJvcGVydGllcywgYW5kIG5vdCByZWNlaXZlciBjYXBhYmlsaXRpZXMuIFRoZSBTRFAg
cGFyYW1ldGVycyBjYW4gYmUgdXNlZCB0byBjb21tdW5pY2F0ZSBiZXR3ZWVuIHNlbmRlci9yZWNl
aXZlciB3aGF0IHRoZXkgd2lzaCB0byBleGNoYW5nZSBiZWZvcmUgc2VuZGluZyBhY3R1YWwgcGF5
bG9hZCwgYnV0IG5vbmUgb2YgdGhlc2UgcGFyYW1ldGVycyBvciB2YWx1ZXMgYXJlICJkb3duZ3Jh
ZGFibGUiIG9yICJpbmNsdXNpdmUgY2FwYWJpbGl0eSBzZXRzIi4gWFMgZG9lcyBub3QgaGF2ZSBz
dWNoIGNvbmNlcHRzLCBhcyBpdCBpcyBhIGxvdy1jb21wbGV4aXR5IGNvZGVjLCBpbnRlbmRlZCBw
cmltYXJpbHkgdG8gcmVwbGFjZSB1bmNvbXByZXNzZWQgdmlkZW8gc3RyZWFtcy4NCg0KU29tZWhv
dywgdGhpcyByYWlzZXMgdGhlIGZvbGxvd2luZzoNCg0KWC4xIEdlbmVyaWMgU0RQIENvbnNpZGVy
YXRpb25zDQogIEkgYmVsaWV2ZSBoZXJlIHdlIGV4cGxhaW4gdGhhdCBwYXJhbWV0ZXJzIGFyZSBk
ZWNsYXJhdGl2ZSBhbmQgcmVwcmVzZW50IGJpdHN0cmVhbS9wYXlsb2FkIHZhbHVlcy9zZXR0aW5n
cy4gU28gYm90aCBzaWRlcyBjYW4gdXNlIHRoZXNlIHRvIGluZGljYXRlIHdoYXQgdGhlIHBheWxv
YWQgd2lsbCBsb29rIGxpa2UuDQoNClguMi4gIEdlbmVyYXRpbmcgdGhlIEluaXRpYWwgU0RQIE9m
ZmVyDQogIE5vdCBtdWNoIHRvIHNheSBoZXJlLiBBcyBJIHVuZGVyc3RhbmQgYW4gU0RQIHNlc3Np
b24gY2FuIGJlIGluaXRpYXRlZCBmcm9tIGVpdGhlciByZWNlaXZlciBvciBzZW5kZXIgc2lkZXM/
IFNvLCB0aGV5IGp1c3Qgc2VuZCBhIHZhbGlkIG1lZGlhIGRlc2NyaXB0aW9uIG9mIHRoZSBjb250
ZW50IHRoZXkgd2FudCB0byBleGNoYW5nZS4gSWYgZWl0aGVyIHNpZGUgY2Fubm90IGhhbmRsZSBj
ZXJ0YWluIHBheWxvYWQgc2V0dGluZ3MsIHRoZW4gaXQgc2hvdWxkIHJlamVjdCB0aGUgb2ZmZXIg
KG9yIGFuc3dlcikuIEFuIG9mZmVyZXIganVzdCBzZW5kcyB3aGF0IGl0IHdhbnRzIHRvIHJlY2Vp
dmUgb3Igc2VuZC4NCg0KWC4zLiAgR2VuZXJhdGluZyB0aGUgU0RQIEFuc3dlcg0KICBJIGRvbid0
IHRoaW5rIHRoZXJlIGlzIGFueXRoaW5nIHNwZWNpYWwgdG8gbWVudGlvbiBoZXJlPyBUaGUgYW5z
d2VyZXIgdGFrZXMgdGhlIGRlY2xhcmF0aXZlIHBhcmFtZXRlcnMgYW5kIGVpdGhlciBhY2NlcHRz
IG9yIHJlamVjdHMgdGhlIHNlc3Npb24uIEl0IHNob3VsZCBOT1QgbW9kaWZ5IHRoZSBvZmZlciBp
biBhbnkgd2F5Lg0KDQpYLjQuICBPZmZlcmVyIFByb2Nlc3Npbmcgb2YgdGhlIFNEUCBBbnN3ZXIN
CiAgSSBkb24ndCB0aGluayB0aGVyZSBpcyBhbnl0aGluZyBzcGVjaWFsIHRvIG1lbnRpb24gaGVy
ZT8gSWYgdGhlIGFuc3dlciBhY2NlcHRlZCB0aGUgb2ZmZXIsIHRoZW4gdGhlIHN0cmVhbSBjYW4g
c3RhcnQuDQoNClguNS4gIE1vZGlmeWluZyB0aGUgU2Vzc2lvbg0KICBNb2RpZnlpbmcgdGhlIHNl
c3Npb24gaXMgcG9zc2libGUsIGJ1dCB0aGlzIGlzIHZlcnkgaW1wbGVtZW50YXRpb24gc3BlY2lm
aWMuIEJhc2ljYWxseSwgbW9kaWZ5aW5nIGEgc2Vzc2lvbiBpcyB2ZXJ5IHNpbWlsYXIgdG8gY3Jl
YXRpb24gb2YgYSBuZXcgc2Vzc2lvbi4gQm90aCBzaWRlcyBzaG91bGQgYWdyZWUgb24gdGhlIHBh
eWxvYWQgdGhleSB3aWxsIGV4Y2hhbmdlLg0KDQoNCkknbSBzb3JyeSB0byBkcmFnIHRoaXMgb3V0
LCBidXQgSSB0aGluayB0aGF0IGhhdmluZyB0aGlzIGNvbnZlcnNhdGlvbiBieSBlbWFpbCBpcyBt
b3JlIGVmZmljaWVudCB0aGFuIHBvc3RpbmcgZHJhZnRzIPCfmIogSSBhcHByZWNpYXRlIHlvdXIg
ZmVlZGJhY2suDQoNClRpbS4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog
Q2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NClNlbnQ6
IEZyaWRheSAyOCBNYXkgMjAyMSAxMDozOQ0KVG86IFRpbSBCcnV5bGFudHMgPFRCUkBpbnRvcGl4
LmNvbT47IFRob21hcyBSaWNodGVyIDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v
djIvdXJsP3U9aHR0cC0zQV9fdGhvbWFzLnJpY2h0ZXItNDBpaXMuZnJhdW5ob2Zlci5kZSZkPUR3
SUdhUSZjPWV1R1pzdGNhVERsbHZpbUVOOGI3alhyd3FPZi12NUFfQ2RwZ25WZmlpTU0mcj1MVHhV
R3VrTENFZkVVZG9fYnEwNDhRJm09VnZzYTd1RkE1ejBEV25CU29ORW52YV80aWo1cmJjUUdPd0xw
X2ktM3o3dyZzPWF1ZUppb1RsdFkwNWt4ZkIyMVJGT3ZTUXN6OGx1bFRveVhRemJjdEpDdmMmZT0+
OyBhdnRAaWV0Zi5vcmcNCkNjOiBKZWFuLUJhcHRpc3RlIExvcmVudCA8amIubG9yZW50QGludG9w
aXguY29tPg0KU3ViamVjdDogUkU6IFtBVlRDT1JFXSBTRFAgZGlyZWN0b3JhdGUgcmV2aWV3IG9m
IGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtanBlZ3hzLTEzDQoNCkhpLA0KDQpGaXJzdCwgcmVnYXJk
aW5nIFJGQyA4NDUwLCB0aGF0IHNwZWNpZmljYXRpb24gd2FzIHByb2JhYmx5IG5ldmVyIHJldmll
d2VkIGJ5IHRoZSBTRFAgZGlyZWN0b3JhdGUsIHNvIEkgY2FuJ3QgcmVhbGx5IGNvbW1lbnQgb24g
dGhhdC4gQnV0LCBJIHNlZSB0aGF0IHRoZSBSRkMgZS5nLiwgc2F5cyBub3RoaW5nIGFib3V0IHdo
ZXRoZXIgdGhlIFNEUCBpbmRpY2F0ZXMgc2VuZGluZyBvciByZWNlaXZpbmcgY2FwYWJpbGl0aWVz
Lg0KDQpTZWNvbmQsIG5vYm9keSBtYW5kYXRlcyB5b3UgdG8gdXNlIFNEUCwgYW5kIG1vc3QgcGFy
dCBvZiB0aGUgc3BlYyBpcyBwcm90b2NvbCBpbmRlcGVuZGVudC4gQnV0LCB0aGUgIlNEUCBPZmZl
ci9BbnN3ZXIiIHNlY3Rpb24gZGVzY3JpYmVzIHRoZSBTRFAgb2ZmZXIvYW5zd2VyIHByb2NlZHVy
ZXMsICpJRiogeW91IGNob29zZSB0byB1c2UgdGhhdCBtZWNoYW5pc20gZm9yIG5lZ290aWF0aW5n
IHRoZSBzZXNzaW9uLg0KDQpUaGlyZCwgSSBkb24ndCB0aGluayB5b3UgbmVlZCB2ZXJ5IG11Y2gg
dGV4dC4gVGhlIGltcG9ydGFudCB0aGluZyBpcyB0byBzYXkgd2hhdCBpcyBwbGFjZWQgaW4gb2Zm
ZXJzIGFuZCBhbnN3ZXJzLCB3aGV0aGVyIHRoZXJlIGFyZSBjb25zdHJhaW50cyB3aGVuIGdlbmVy
YXRpbmcgdGhlIGFuc3dlciwgYW5kIHdoZXRoZXIgdGhlcmUgYXJlIGNvbnN0cmFpbnRzIHdoZW4g
aXQgY29tZXMgdG8gbW9kaWZ5aW5nIHRoZSBzZXNzaW9uLiBBbmQsIHlvdSBkbyBOT1QgIG5lZWQg
dG8gc3BlY2lmeSBIT1cgdG8gbW9kaWZ5IGEgc2Vzc2lvbiwgYnV0IHdoZXRoZXIgdGhlcmUgYXJl
IHBheWxvYWQtc3BlY2lmaWMgY29uc3RyYWludHMgd2hlbiBkb2luZy4NCg0KUmVnYXJkcywNCg0K
Q2hyaXN0ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRpbSBCcnV5bGFu
dHMgPFRCUkBpbnRvcGl4LmNvbT4NClNlbnQ6IHBlcmphbnRhaSAyOC4gdG91a29rdXV0YSAyMDIx
IDkuNDkNClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u
Y29tPjsgVGhvbWFzIFJpY2h0ZXIgPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92
Mi91cmw/dT1odHRwLTNBX190aG9tYXMucmljaHRlci00MGlpcy5mcmF1bmhvZmVyLmRlJmQ9RHdJ
RkFnJmM9ZXVHWnN0Y2FURGxsdmltRU44YjdqWHJ3cU9mLXY1QV9DZHBnblZmaWlNTSZyPUxUeFVH
dWtMQ0VmRVVkb19icTA0OFEmbT1nZkI0UEYtdlZCVy1IVnhjU3hDeDA3TENoUTFDU2VwWU4zSm51
dlBadmhnJnM9V2cwOGkzMjEzYkN5UDBZYjhIajVpaHBCV2otZGxyVm5LRGRqZ2dPSmJxQSZlPT47
IGF2dEBpZXRmLm9yZw0KQ2M6IEplYW4tQmFwdGlzdGUgTG9yZW50IDxqYi5sb3JlbnRAaW50b3Bp
eC5jb20+DQpTdWJqZWN0OiBSRTogW0FWVENPUkVdIFNEUCBkaXJlY3RvcmF0ZSByZXZpZXcgb2Yg
ZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1qcGVneHMtMTMNCg0KSGkgQ2hyaXN0ZXIsDQoNCkknbSBh
IGxpdHRsZSBiaXQgc3R1Y2sgaW4gaG93IHRvIHJlc29sdmUgYW5kIGFkZHJlc3MgeW91ciBjb21t
ZW50cy4gT24gb25lIGhhbmQgSSB1bmRlcnN0YW5kIHRoYXQgd2Ugd2FudCB0aGUgdGV4dCB0byBi
ZSBjbGVhciwgYnV0IG9uIHRoZSBvdGhlciBoYW5kIHdlIGRvIG5vdCB3YW50IHRvIHJlcGVhdCBT
RFAgc3BlY2lmaWNzIHRvbyBtdWNoLiBTRFAgaXMganVzdCBvbmUgd2F5IHRvIG5lZ290aWF0ZSBh
IHNlc3Npb24sIGFuZCBpbiB0aGUgY2FzZSBvZiBYUyBpdCBpcyBub3QgdGhlIG1vc3QgY29tbW9u
bHkgdXNlZCBvbmUuIFhTIGlzIG5vdCByZWFsbHkgaW50ZW5kZWQgZm9yIHRoZSBjbGFzc2ljYWwg
dmlkZW8tY2FsbCBjYXNlLCBidXQgcmF0aGVyIHRvIHN0cmVhbSBoaWdoLXF1YWxpdHkgdmlkZW8g
Y29udGVudCBpbiBhIHByb2Zlc3Npb25hbCBlbnZpcm9ubWVudC4gSXQgY2FuIGJlIHVzZWQgZm9y
IHZpZGVvIGNvbmZlcmVuY2luZywgYnV0IGJldHRlciBzdWl0ZWQgY29kZWNzIGV4aXN0IGZvciB0
aGF0IHVzZS1jYXNlLg0KDQpIb3dldmVyLCB3aGF0IGlzIGltcG9ydGFudCB0byBsYXkgb3V0IGNv
cnJlY3RseSBpcyB0aGUgbWFwcGluZyBvZiB0aGUgbWVkaWEgcGFyYW1ldGVycyBpbnRvIHRoZSBh
PWZtdHAgZmllbGQgb2YgU0RQLCBiZWNhdXNlIHRoaXMgaXMgYWN0dWFsbHkgdXNlZCBieSBtYW55
IG90aGVyIHByb3RvY29scyAoc28sIGp1c3QgdGhlIG1lZGlhIGRlc2NyaXB0aW9uIHBhcnQgb2Yg
U0RQIGlzIHVzZWQpLg0KDQpPcmlnaW5hbGx5LCB3ZSBiYXNlZCBvdXIgZHJhZnQgdGV4dCBvbiBS
RkMgODQ1MCAoVkMtMiBIUSBSVFAgUGF5bG9hZCkuIEluIHRoYXQgcmVzcGVjdCwgd2hhdCBpcyB3
cml0dGVuIHRoZXJlIGtpbmQgb2YgZml0cyBleGFjdGx5IHdoYXQgd2Ugd2FudCB3aXRoIFhTLiBH
aXZlbiB0aGF0IHRoaXMgaXMgYSBwdWJsaXNoZWQgUkZDLCB3ZSBhcmUgcHV6emVsZWQgYSBiaXQg
YXMgdG8gd2h5IG91ciBkcmFmdCB3b3VsZCBuZWVkIHRvIGVsYWJvcmF0ZSBzbyBleHRlbnNpdmVs
eSBvbiBTRFAuIEZvciBzdXJlLCB3ZSdkIGxpa2UgdG8gYWxsb3cgU0RQIG9mZmVyL2Fuc3dlciBu
ZWdvdGlhdGlvbiB3aXRoIFhTLiBCdXQgdGhpcyBpcyB2ZXJ5IHNpbXBsZTogZWFjaCBzaWRlIHRl
bGxzIHRoZSBvdGhlciBzaWRlIHdoYXQgaXQgc3VwcG9ydHMsIGFuZCB0aGF0J3MgaXQuIEluIFhT
IHRoZSBwYXJhbWV0ZXJzIGFyZSBkZWNsYXJhdGl2ZSwgbWVhbmluZyAoYXQgbGVhc3QgdGhhdCdz
IHdoYXQgd2Ugd2FudCB0byBleHByZXNzKSB0aGF0IGVhY2ggcGFyYW1ldGVyIGlzIHJlcHJlc2Vu
dHMgYW4gZXhhY3QgdmFsdWUgYW5kIGlzIG5vdCAiaW5jbHVzaXZlIiBpbnRvIGEgcmFuZ2Ugb2Yg
bGVzc2VyIHZhbHVlcy4gSW4gb3RoZXIgd29yZHMsIHRoZSBvdGhlciBzaWRlIGNhbm5vdCBleHBl
Y3QgdGhhdCBhICJsZXNzZXIiIHZhbHVlIG9mIGEgcGFyYW1ldGVyIGNhbiB3b3JrLg0KDQpZb3Vy
IHByb3Bvc2VkIHN0cnVjdHVyZSBpcyBqdXN0IHRvIGVsYWJvcmF0ZSBhbmQgb3V0IG9mIHNjb3Bl
LiBBcyBzdWNoLCBJIHdvdWxkIGFzayB5b3UgdG8gY29uc2lkZXIgdGhlIGV4YW1wbGUgb2YgUkZD
IDg0NTAgKHdoZXJlIHRoZSB1c2UtY2FzZSBhbmQgcHVycG9zZSBtYXRjaGVzIHRoYXQgb2Ygb3Vy
IGRyYWZ0KS4gRm9yIGV4YW1wbGU6IFdoeSBkbyB3ZSBuZWVkIHRvIHN0YXRlIGFueXRoaW5nIHNw
ZWNpZmljIG9uICJNb2RpZnlpbmcgdGhlIFNlc3Npb24iPyBJc24ndCB0aGlzIGxheWVkIG91dCBi
eSBTRFAgb24gaG93IHRvIG1vZGlmeSBhIHNlc3Npb24/IFRoZXJlJ3Mgbm90aGluZyBzcGVjaWZp
YyB0byBiZSBwdXQgaW4gb3VyIGRyYWZ0ICh3ZSBkbyBub3Qgd2FudCB0byBwcmV2ZW50LCBub3Qg
c3VnZ2VzdCB0aGlzIGZ1bmN0aW9uYWxpdHkpLg0KDQpJIGhvcGUgeW91IGNhbiB1bmRlcnN0YW5k
IG91ciBkaWZmaWN1bHR5IHdpdGggeW91ciByZW1hcmtzIGFuZCBjb21tZW50cy4gT3VyIHByb3Bv
c2FsIGFzIHN1Y2ggaXMgdG8ga2VlcCB0aGUgdGV4dCBhYm91dCBTRFAgdmVyeSBzaG9ydCBhbmQg
c2ltcGxlLiBUaGUgUlRQIFBheWxvYWQgZHJhZnQgY2FuIGJlIHVzZWQgd2l0aCBTRFAsIGJ1dCBp
dCdzIGNlcnRhaW5seSBub3QgdGhlIG9ubHkgd2F5Lg0KDQpJIHdpbGwgYmUgcHJlcGFyaW5nIGFu
IHVwZGF0ZWQgZHJhZnQgd2hpY2ggdHJpZXMgdG8gYmUgdmVyeSBtaW5pbWFsIG9uIHRoZSBTRFAg
c3BlY2lmaWNzLiBVbmxlc3MgYW55dGhpbmcgaXMgdGVjaG5pY2FsbHkgd3JvbmcsIEkgcmVhbGx5
IGhvcGUgeW91IGNhbiBhZ3JlZSB0byBpdCBhbmQgbW92ZSBmb3J3YXJkIHdpdGggdGhlIHB1Ymxp
Y2F0aW9uIHByb2Nlc3MuDQoNCkJlc3QgcmVnYXJkcywNClRpbS4NCg0KDQotLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KRnJvbTogYXZ0IDxhdnQtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxm
IE9mIENocmlzdGVyIEhvbG1iZXJnDQpTZW50OiBXZWRuZXNkYXkgMjYgTWF5IDIwMjEgMTg6NDMN
ClRvOiBUaG9tYXMgUmljaHRlciA8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy
L3VybD91PWh0dHAtM0FfX3Rob21hcy5yaWNodGVyLTQwaWlzLmZyYXVuaG9mZXIuZGUmZD1Ed0lG
QWcmYz1ldUdac3RjYVREbGx2aW1FTjhiN2pYcndxT2YtdjVBX0NkcGduVmZpaU1NJnI9TFR4VUd1
a0xDRWZFVWRvX2JxMDQ4USZtPWdmQjRQRi12VkJXLUhWeGNTeEN4MDdMQ2hRMUNTZXBZTjNKbnV2
UFp2aGcmcz1XZzA4aTMyMTNiQ3lQMFliOEhqNWlocEJXai1kbHJWbktEZGpnZ09KYnFBJmU9Pjsg
YXZ0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0FWVENPUkVdIFNEUCBkaXJlY3RvcmF0ZSByZXZp
ZXcgb2YgZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1qcGVneHMtMTMNCg0KVGhpcyBpcyBhIHN0cnVj
dHVyZSB0aGF0IGlzIHR5cGljYWxseSB1c2VkIGZvciBTRFAgb2ZmZXIvYW5zd2VyIHByb2NlZHVy
ZXM6DQoNClguICBTRFAgT2ZmZXIvQW5zd2VyIFByb2NlZHVyZXMNCiAgICAgWC4xLiAgR2VuZXJp
YyBTRFAgQ29uc2lkZXJhdGlvbnMNCgk8SGVyZSB5b3UgY2FuIGRlc2NyaWJlIHRoaW5ncyB3aGlj
aCBhcHBseSB0byBib3RoIG9mZmVycyBhbmQgYW5zd2Vycz4NCiAgICAgWC4yLiAgR2VuZXJhdGlu
ZyB0aGUgSW5pdGlhbCBTRFAgT2ZmZXINCgk8SGVyZSB5b3UgZGVzY3JpYmUgaG93IHRoZSBpbml0
aWFsIFNEUCBvZmZlciBmb3IgdGhlIHNlc3Npb24gaXMgZ2VuZXJhdGVkPg0KICAgICBYLjMuICBH
ZW5lcmF0aW5nIHRoZSBTRFAgQW5zd2VyDQoJPEhlcmUgeW91IGRlc2NyaWJlIGhvdyB0aGUgYW5z
d2VyZXIgZ2VuZXJhdGVzIHRoZSBTRFAgYW5zd2VyLCBpbmNsdWRpbmcgd2hldGhlciBwYXJhbWV0
ZXJzL3BhcmFtZXRlciB2YWx1ZXMgbmVlZCB0byBiZSBhIHN1YnNldCBvZiB0aGUgcGFyYW1ldGVy
cy9wYXJhbWV0ZXIgdmFsdWVzIGluIHRoZSBvZmZlciBldGM+DQogICAgIFguNC4gIE9mZmVyZXIg
UHJvY2Vzc2luZyBvZiB0aGUgU0RQIEFuc3dlcg0KICAgICA3LjUuICBNb2RpZnlpbmcgdGhlIFNl
c3Npb24NCgk8SGVyZSB5b3UgZGVzY3JpYmUgY29uc3RyYWludHMgcmVsYXRlZCB0byBtb2RpZmlj
YXRpb24gb2YgdGhlIHNlc3Npb24sIGluY2x1ZGluZyB3aGV0aGVyIHRoZXJlIGFyZSBjZXJ0YWlu
IHBhcmFtZXRlcnMvcGFyYW1ldGVyIHZhbHVlcyB0aGF0IHlvdSBjYW5ub3QgbW9kaWZ5IGV0Yz4N
Cg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy
b206IGF2dCA8YXZ0LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBDaHJpc3RlciBIb2xt
YmVyZw0KU2VudDoga2Vza2l2aWlra28gMjYuIHRvdWtva3V1dGEgMjAyMSAxOS4zOA0KVG86IFRo
b21hcyBSaWNodGVyIDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9
aHR0cC0zQV9fdGhvbWFzLnJpY2h0ZXItNDBpaXMuZnJhdW5ob2Zlci5kZSZkPUR3SUNBZyZjPWV1
R1pzdGNhVERsbHZpbUVOOGI3alhyd3FPZi12NUFfQ2RwZ25WZmlpTU0mcj1MVHhVR3VrTENFZkVV
ZG9fYnEwNDhRJm09THRlZlFpTGhkclh3VXljYWg3Wm1zYXlrX2R0SEYtaE1FQndIbzZEcGV0MCZz
PS1UTzFRZjdsMV9xYzRrbFJLdmJ1VzhfZUQ0TDhmODVPQjVEYWhiMkxRR0UmZT0+OyBhdnRAaWV0
Zi5vcmcNClN1YmplY3Q6IFJlOiBbQVZUQ09SRV0gU0RQIGRpcmVjdG9yYXRlIHJldmlldyBvZiBk
cmFmdC1pZXRmLXBheWxvYWQtcnRwLWpwZWd4cy0xMw0KDQpIaSwNCg0KPj4gVW5mb3J0dW5hdGVs
eSBJIGRvbid0IHRoaW5rIHdoYXQgeW91IGV4cGxhaW4gYWJvdmUgaXMgdmVyeSBjbGVhciBpbiAN
Cj4+IHRoZSB0ZXh0Lg0KPj4gDQo+PiBDb25zaWRlciB0aGUgZm9sbG93aW5nLg0KPj4gDQo+PiBU
aGUgb2ZmZXJlciBzZW5kcyBhbiBvZmZlci4gVGhlIG9mZmVyZXIgc3BlY2lmaWVzIHRoZSBjaGFy
YWN0ZXJpc3RpY3MgDQo+PiB0aGF0IHRoZSBvZmZlcmVyIHdhbnRzIHRvIHJlY2VpdmUuIFNpbWls
YXJseSwgdGhlIGFuc3dlciBzcGVjaWZpZXMgDQo+PiB0aGUgY2hhcmFjdGVyaXN0aWNzIHRoYXQg
dGhlIGFuc3dlcmVyIHdhbnRzIHRvIHJlY2VpdmUgLSB0aGUgYW5zd2VyZXIgDQo+PiBkb2VzIE5P
VCBzcGVjaWZ5IHdoYXQgaXQgaXMgZ29pbmcgdG8gc2VuZC4gd2hpY2ggSSB0aGluayB0aGUgdGV4
dCBpcyANCj4+IGN1cnJlbnRseSBkZXNjcmliaW5nLg0KPg0KPiBTb3JyeSB0byBzb3VuZCBjb25m
dXNlZCwgYnV0IG1heWJlIHlvdSBjb3VsZCBleHBsYWluIGEgYml0IGJldHRlci4gVG8gbXkgdW5k
ZXJzdGFuZGluZywgaXQgaXMgdGhlIG9mZmVyZXIgdGhhdCBkZXNjcmliZXMgd2hhdCBpdCBvZmZl
cnMgdG8gc2VuZCwgYW5kIG5vdCB0aGUgb3RoZXIgd2F5IGFyb3VuZD8gDQo+IE1heWJlIEkgbWlz
dW5kZXJzdGFuZCBzb21ldGhpbmcgdmVyeSBmdW5kYW1lbnRhbD8gU29ycnkgdG8gYXNrIHRoZXNl
IGVsZW1lbnRhcnkgcXVlc3Rpb25zLCBidXQgdGhpcyBpcyBpbXBvcnRhbnQgZm9yIHRoZSB0ZXh0
Lg0KDQpJbiBTRFAgT2ZmZXIvQW5zd2VyLCB0aGUgZGVmYXVsdCBpcyB0byBpbmRpY2F0ZSB3aGF0
IHlvdSBhcmUgd2lsbGluZyB0byBSRUNFSVZFIDopDQoNClR5cGljYWxseSB5b3VyIHJlY2Vpdmlu
ZyBjYXBhYmlsaXRpZXMgYWxzbyBpbXBsaWNpdGx5IGluZGljYXRlIHdoYXQgeW91IGFyZSBhYmxl
IHRvIHNlbmQuIEZvciBleGFtcGxlLCBpZiBJIGFtIGluZGljYXRpbmcgdGhhdCBJIGFtIHdpbGxp
bmcgdG8gcmVjZWl2ZSBjb2RlYyBYIGl0IG5vcm1hbGx5IG1lYW5zIHRoYXQgSSBhbSBhbHNvIGFi
bGUgdG8gc2VuZCBjb2RlYyBYLg0KDQogQnV0LCB0aGVyZSBhcmUgY2FzZXMgd2hlcmUgdGhhdCBp
cyBub3QgdHJ1ZSwgZXNwZWNpYWxseSB3aGVuIGl0IGNvbWVzIHRvIHZpZGVvIGNvZGVzIHdoZXJl
IHlvdSB0eXBpY2FsbHkgaGF2ZSBtb3JlIHBhcmFtZXRlcnMgYXNzb2NpYXRlZCB3aXRoIHRoZSBj
b2RlYywgYW5kIG9uZSBuZWVkcyB0byBleHBsaWNpdGx5IGluZGljYXRlIHNlbmRpbmcgY2FwYWJp
bGl0aWVzLiANCg0KLS0tDQoNCj4+ICJUaGUgcmVjZWl2ZXIgU0hBTEwgaWdub3JlIGFueSB1bnJl
Y29nbml6ZWQgcGFyYW1ldGVyIG9yIGludmFsaWQgDQo+PiBwYXJhbWV0ZXIgdmFsdWUuIg0KPj4g
DQo+PiBGaXJzdCwgSW4gbXkgb3BpbmlvbiBpbnZhbGlkIHBhcmFtZXRlcnMgdmFsdWVzIHNoYWxs
IHRyaWdnZXIgYW4gZXJyb3IuDQo+PiANCj4+IFNlY29uZCwgd2hhdCBpcyBhbiB1bnJlY29nbml6
ZWQgcGFyYW1ldGVyPw0KPg0KPiBJIHdvbmRlciB3aHkgd2UgbmVlZCB0byBzcGVjaWZ5IHRoaXMs
IGkuZS4gd2hhdCBhIHJlY2VpdmUgZG9lcyBhYm91dCANCj4gcGFyYW1ldGVycyBpdCBkb2VzIG5v
dCByZWNvZ25pemU/IEVzc2VudGlhbGx5LCB0aGlzIGlzIGEgcHJvYmxlbSBvZiANCj4gImZvcmV3
YXJkIGNvbXBhdGliaWxpdHkiLiBXb3VsZG4ndCBpdCBiZSBhIG1hdHRlciBvZiBpbXBsZW1lbnRh
dGlvbiB3aGV0aGVyIHRoZSByZWNlaXZlciBhY2NlcHRzIGFuIG9mZmVyIChub3RlIHdlbGwsIHRo
ZSByZWNlaXZlciksIGFuZCBhdHRlbXB0cyB0byBkZWNvZGUgYSBzdHJlYW0gb24gYSAiYmVzdCBl
ZmZvcnQiIGJhc2lzLCBrZWVwaW5nIGluIG1pbmQgdGhhdCB0aGUgc3RyZWFtIGl0c2VsZiBpbmNs
dWRlcyBhZGRpdGlvbmFsIG1lYW5zIHRvIGlkZW50aWZ5IHJlcXVpcmVkIGNhcGFiaWxpdGllcyBu
ZWNlc3NhcnkgZm9yIGEgc3VjY2Vzc2Z1bCBkZWNvZGUuDQo+DQo+IElmIHRoYXQgaXMgbm90IGFu
IG9wdGlvbiwgd2Ugd291bGQvY291bGQgbmVlZCBtZWFucyB0byBpZGVudGlmeSB0aGUgDQo+IHR5
cGUgb2YgcGFyYW1ldGVycyBpbiBhIGZvcmV3YXJkIGNvbXBhdGlibGUgd2F5LiBJLmUuLCBjb252
ZW50aW9ucyBieSB3aGljaCB3ZSB3b3VsZCBpZGVudGlmeSBpbiB0aGUgZnV0dXJlIHBhcmFtZXRl
cnMgYSByZWNlaXZlciBjYW4gc2FmZWx5IGlnbm9yZSBhbmQgYXR0ZW1wdCB0byBkZWNvZGUsIGFu
ZCBwYXJhbWV0ZXJzIGEgcmVjZWl2ZXIgY2Fubm90IHNhZmVseSBpZ25vcmUuDQoNCkkgdGhpbmsg
aXQgaXMgZmluZSB0byBzYXkgdGhhdCB1bnJlY29nbml6ZWQgcGFyYW1ldGVycyBzaGFsbCBiZSBp
Z25vcmVkLiBJdCBpcyB0aGVuIHVwIHRvIGZ1dHVyZSBzcGVjaWZpY2F0aW9ucyB0byB3b3JyeSBh
Ym91dCBiYWNrd2FyZCBjb21wYXRpYmlsaXR5LCByYXRoZXIgdGhhbiB0aGlzIHNwZWNpZmljYXRp
b24gd29ycnlpbmcgYWJvdXQgZm9yd2FyZCBjb21wYXRpYmlsaXR5Lg0KDQo+PiBBbHNvLCB0aGUg
dGV4dCBkb2VzIG5vdCBzYXkgd2hhdCByZXN0cmljdGlvbnMgKGlmIGFueSkgdGhlcmUgYXJlIHdo
ZW4gDQo+PiBpdCBjb21lcyB0byBtb2RpZnkgdGhlIHN0cmVhbSBkdXJpbmcgYSBzZXNzaW9uLiBJ
cyBpdCBhbGxvd2VkIHRvIA0KPj4gbW9kaWZ5IGFueS9hbGwgY2hhcmFjdGVyaXN0aWNzPw0KPg0K
PiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgeW91IGNhbm5vdCBtb2RpZnkgY2hhcmFjdGVyaXN0
aWNzIGR1cmluZyBhIA0KPiBzZXNzaW9uLiBJZiB5b3UgbmVlZCB0byBtb2RpZnksIHlvdSBuZWVk
IHRvIHNldHVwIGEgbmV3IHNlc3Npb24gYW5kIA0KPiBjYW5jZWwgdGhlIGN1cnJlbnQgb25lLiBG
b3IgSlBFRyBYUyBzdHJlYW0gZGVjb2RlcnMsIG9uZSBjYW5ub3QgZXhwZWN0IHRoYXQgYW4gaW5z
dGFuY2lhdGVkIGRlY29kZXIgY2FuIGRlY29kZSBmcm9tIG1vZGlmaWVkIHBhcmFtZXRlcnMgaW4g
bWlkLXN0cmVhbSBsZXZlbC4gVGhhdCBpcywgaWYgeW91IHN0YXJ0IGRlY29kaW5nIGluIGZ1bGwt
SEQsIGFuZCB0aGVuIHN0cmVhbSBwYXJhbWV0ZXJzIGJlY29tZSA4SywgdGhlIGRlY29kZXIgd2ls
bCBoYXZlIHRvIGFib3J0Lg0KDQpUaGVzZSBraW5kIG9mIHRoaW5ncyBuZWVkIHRvIGJlIHNwZWNp
ZmllZC4gSSBkb24ndCB0aGluayBpdCBuZWVkcyB0byBiZSBmb3JiaWRkZW4gdG8gdHJ5IHRvIG1v
ZGlmeSBzb21ldGhpbmcsIGJlY2F1c2UgdGhlcmUgY291bGQgYmUgdGV4dCB0aGF0IHN0cm9uZ2x5
IHJlY29tbWVuZHMgYWdhaW5zdCBkb2luZyBpdC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkF1ZGlvL1Zp
ZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQphdnRAaWV0Zi5vcmcNCmh0dHBzOi8vdXJs
ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21h
aWxtYW5fbGlzdGluZm9fYXZ0JmQ9RHdJQ0FnJmM9ZXVHWnN0Y2FURGxsdmltRU44YjdqWHJ3cU9m
LXY1QV9DZHBnblZmaWlNTSZyPUxUeFVHdWtMQ0VmRVVkb19icTA0OFEmbT1MdGVmUWlMaGRyWHdV
eWNhaDdabXNheWtfZHRIRi1oTUVCd0hvNkRwZXQwJnM9MXZaVHVGakktUWJleFA1b1g5cGdhMzVk
Wlp6dGhYR2duN1M4WmdvZDlMRSZlPQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UN
CmF2dEBpZXRmLm9yZw0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91
PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19hdnQmZD1Ed0lDQWcmYz1l
dUdac3RjYVREbGx2aW1FTjhiN2pYcndxT2YtdjVBX0NkcGduVmZpaU1NJnI9TFR4VUd1a0xDRWZF
VWRvX2JxMDQ4USZtPUx0ZWZRaUxoZHJYd1V5Y2FoN1ptc2F5a19kdEhGLWhNRUJ3SG82RHBldDAm
cz0xdlpUdUZqSS1RYmV4UDVvWDlwZ2EzNWRaWnp0aFhHZ243UzhaZ29kOUxFJmU9DQpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQXVkaW8vVmlkZW8gVHJh
bnNwb3J0IENvcmUgTWFpbnRlbmFuY2UNCmF2dEBpZXRmLm9yZw0KaHR0cHM6Ly91cmxkZWZlbnNl
LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9s
aXN0aW5mb19hdnQmZD1Ed0lHYVEmYz1ldUdac3RjYVREbGx2aW1FTjhiN2pYcndxT2YtdjVBX0Nk
cGduVmZpaU1NJnI9TFR4VUd1a0xDRWZFVWRvX2JxMDQ4USZtPVZ2c2E3dUZBNXowRFduQlNvTkVu
dmFfNGlqNXJiY1FHT3dMcF9pLTN6N3cmcz1vaUwycGRsN2hfNkxWWS00RTg4aFZWSTFOb0RXczZq
Qk9MYjFyV3JBX25JJmU9DQo=


From nobody Mon May 31 07:53:31 2021
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827B33A1AD6 for ; Mon, 31 May 2021 07:53:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level: 
X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqYIjitxQeLD for ; Mon, 31 May 2021 07:53:24 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0600.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::600]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 008DE3A1AD3 for ; Mon, 31 May 2021 07:53:23 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aDaYUIP/HhAKEsyuRvX/EdlUIaOL7NB6xRF1sTndZb9/VxyBq8obvlQt12lycQhKNMHdRlQdP9wqKXlMt1Ed6536VuimrRlH7C7mlDzi8SLVHnVLKpkPtNvVsLeukCxyXy89Yh8e4E2i5jt3C7JudWCOMzyN47q4pO4Gt7qxOCZyVk9Tc1kHOr0rvkXRLLMPQnkcNGwhzOXwH5xhc48Wpyb0jvuPCxM7jv63s0WARhE5k82gB4hBvcSGWxlJAmE90ilAd29ClgfWbVJidSLfB2ynTXaApn/iRrNpqc9Q0LZTE8xElUlSd51fnnA03O+Ld+068OIZaD1A1M4keORDLA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eMLNJPwiAV6+bCg3L4Mfu6SWArSbM03mi5P9nBn951g=; b=NXHHJZNOq1vu8zU0EJLTuekjoiEFEJm7iVQtyg27oSlOgeu+mUjRvG8DC+nI0Wkd1048SJ/yx/nbI4jRfKgozh2aAbp3XwLs349xt0prAUeTQCE9xsJpsVUeDY99KZvL01t1dHx4E4ItKijHQGOkSVa59s/sk/7d45vy971JZFXTmBrE+UzlGMFYi5Zf4Fh6Ks/098kWw70fUknk1GCTvCxWe8CAsAVi3BrpdUNaNJeyKqq2CCIohmITjPcxgrx+P/1rb1sk+cyuTYpkaduU8EOlVWRbuBwjUoXFTy091NygNLZfjoLDC6qXh9dzxDZ3mODRsZG4iolxHSgnXp1p4A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eMLNJPwiAV6+bCg3L4Mfu6SWArSbM03mi5P9nBn951g=; b=rEG0dcBDeVKF5h1bWuA8bINhf82cPomKnHijWAO6UzmcMI7sob6VnPVOdUbFFFLSTRQVvlSo+N+ntUqPVAqhuoAmjUAdqgYLZHxFam9LAjSCCBRB2U3cD9sEuwQC5altXzQv9FjEEJ9KvhDt08CzgIOx9532fnq9qk+CcnaKe8I=
Received: from AM0PR07MB3860.eurprd07.prod.outlook.com (2603:10a6:208:4c::18) by AM0PR07MB4019.eurprd07.prod.outlook.com (2603:10a6:208:47::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.12; Mon, 31 May 2021 14:53:15 +0000
Received: from AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::b10f:ebc0:80d:db2]) by AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::b10f:ebc0:80d:db2%7]) with mapi id 15.20.4195.017; Mon, 31 May 2021 14:53:14 +0000
From: Christer Holmberg 
To: Tim Bruylants , Thomas Richter , "avt@ietf.org" 
CC: Jean-Baptiste Lorent 
Thread-Topic: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
Thread-Index: AddLKBOH9HzaEV4jTtmQ8TPYzmKsqwFVwo+gABfRKwAAFpWSgABEymJQAABwR+AAT0NxwAAES3xQAAEQhVAAkqc4oAAOiNkwAACTaHAAASFDQA==
Date: Mon, 31 May 2021 14:53:14 +0000
Message-ID: 
References:    <7aa5e890-47c5-cdb7-5657-26864cec3d4c@iis.fraunhofer.de>        
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: intopix.com; dkim=none (message not signed) header.d=none;intopix.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [80.248.247.159]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3e8dbd4c-c6c8-4c69-a6f4-08d92443d1b9
x-ms-traffictypediagnostic: AM0PR07MB4019:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ZUZx+CgP+6AClbBAJiYVDK2TRJMBu7HVxJlVEfjcDBHPYi4tTLpPkV4/E1GNhohbcIYq475/j7Jnv2e5I0pl0qe9arFh/sCGs5/vGqE8+tb5yJp8vDzBPoXf3U5kPRqNoQK1+wBA3K7riQITvfKUjQvv5HSxwSKoFzJAS7STAQ3Us2cDeet6PraTWN9VFtuP/VNKtTYvRZHNhcEjGkVK+EnlI/nI1Js5dftPdQkHHqqBvY1lF45kxIp9Q6bc5Xjz0V7YyIUOMpWlob8JzXnwjH1ofTlpGAN8Y4WUBjV3bhsCfgNSK9D33qS3hhdFHS9Y+MMJwIWsjCML1g3t3VljgX0Pq8IvnPJZJlP4kwlBF9r8aQ0nCChaEEmcQ2mNKhJTw7m2gnMXOiyAJ8dp6TV7r57RR2YnlZZlFTB9dERcbO0VtVEZvGH1/ehz9RKB2gX5CSsMBT2d+Y/s3rRSlE/Vb4JzeknvhWGLnJfSSuofFkTDiS82WKosy8b4OvJh7EVMXhgAbCnnAdT1bqCmF9qPGt7XOEfTzIqhW08wrEo9MIb6PlwemDUOamxS8m3zOyJvXEvP0D6CQUivLz3KTU5Ji/Cet/G3mEGMqB032QRS0d+6SFTqe1cGPxRBZsVxkCXoE6omDF+UXRrNHXdogP2GKYn+Xkv3RwSzG/f3rEIvaOkcEKN7MVOPehhFUA63by1orTEChReUm0VkoVA2TNgDGkxBdh57AP9NrWIJ9twvIHU=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:AM0PR07MB3860.eurprd07.prod.outlook.com; PTR:; CAT:NONE;  SFS:(4636009)(376002)(136003)(366004)(39860400002)(346002)(396003)(55016002)(83380400001)(316002)(26005)(52536014)(71200400001)(66476007)(8676002)(30864003)(53546011)(7696005)(76116006)(66556008)(66446008)(9686003)(8936002)(64756008)(66946007)(2906002)(44832011)(478600001)(86362001)(186003)(110136005)(6506007)(38100700002)(4326008)(5660300002)(33656002)(966005)(122000001); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?utf-8?B?WURKeWhDNlFSRlYwS0t1UTVGR1NHTFkxZzhNdEpscWFrWVpZV3hmWTRxVktR?= =?utf-8?B?b3llOHFBUUhYQzBuVm9sU0tRelBocko0OHNCK0hWN2hUUHJsb1RXSDAyei9p?= =?utf-8?B?OUpJaW02VURPVnQ2U3RXL0hYVVRGLzRGaDJIRmRlcHVCWDJiTEljQ3NqTkR1?= =?utf-8?B?Wkk5bzJ4WkFXWms5Zm5kN214SHFKZERBdldKOXc5NmtYalY3aGYvMGpQdFZK?= =?utf-8?B?NHUraitYSnJpUFhYdkZ2and2VVFRQUtteXJwVGRnQ2sybzEzY01mcThWZlVJ?= =?utf-8?B?ZU40YmdtTnBWSUFnN3VWbXZjY2x5RlordU5tQTI3azFzZXE4aHpra25kQktB?= =?utf-8?B?VEsxRmxOT3FobGkzc0dyV0o5VFNqOEtZMUVMczlqWFMvTk1ackJHWkRIazlD?= =?utf-8?B?L251QmhjcVJQUHJUZEo2bWNIWlBkRXFsclVwZkdPVms0akZjTlJwZ1NsdzNH?= =?utf-8?B?S2Q0U3U4T3ZkczZsakpudW9UemhLNnE4dTVyaXpUTVlCNEVWSTVPNCtGU3ZR?= =?utf-8?B?YjFmQW1xVlhYc3Y3ZTlPbXIxdEVPbjFEK1lXU0Z3b2s5alVDbUZHaTNRNHpG?= =?utf-8?B?MmxpQlo0S1V5K0l5QlRrb3BXSDI2VUpTQUQrcnFxSzBDWkRSSWExajljNldW?= =?utf-8?B?dEphYWxVWVZFSEl5UFZ0Z21pZWc4emoxR09kdmZjMWorTWN3TTBsQTVFVm9p?= =?utf-8?B?V3BEMFNPTk1LNVBvcG5OKzBWRUFzS2d0R0FtbExMdFpnQXpqZkpJYXkrOXE0?= =?utf-8?B?QU5ZR2Qxc2svYlY5K3piT2l5MUV0T21YUWZDeHMxQjJ6cGN5d3JXWlNaaVZI?= =?utf-8?B?NjYxaFNFRkUzSUxqV2dENmRsM3FFdmtwWVNsTk4vcFVEVEpvSWI0MkNaZHBp?= =?utf-8?B?WWF4TGlIeGYvdTRIdVNzWGhPQjMvZE1LcnkvWEZ3RmhCQjNZVGZRK09ONUFM?= =?utf-8?B?V1pRYjMyaTdPaDV5MW1TLzU3OXNTRFJLZXd5Q3g3RUQ4OXNHK0xJRFBQQ2x5?= =?utf-8?B?a2VMN2JxeVFtaW5ISVZPUGxMQ2FFc2R4YXl3OGJ5bnRzeEpGUTJ6SUljNmJv?= =?utf-8?B?NWd4NEVVclo1NFBMaDY3emNIQXJ1eWV6VlZXOTd4L0xpVkhIbytHRWlhVko5?= =?utf-8?B?K3BQbVovVG1aSU04dG85YXl1bUdJQWxqYXVMV1ZpRzVQRXlwN3U2eHc3Y3Zp?= =?utf-8?B?c2VSS1UzVzBaTU1pZW1UWElNcHNTYmZEdG9WRlZBQ0FlMFVoMHh6d1U3OEo2?= =?utf-8?B?a09xc3kzTmJRNjd1ejhIOGltcjV6d1VmVjJrMVN2YklleWlQOVBmYWhxUlR3?= =?utf-8?B?RWJWbFhCbnVwMXB6ZFdRbHVvUytoTlM4K0RHOWJLZWNka2U3Q0Y5THlEVmdp?= =?utf-8?B?OXZadXZuNWcrNWdWVEc2VXg1NDlaTnkwWlhxZkFmY2l5MGJBdnhHUVZ5NWpN?= =?utf-8?B?WkR5QkdYR0ZkYmErKzg2ckk3MGtlQnp2UnJJdy9TQ09BL0pxUFIramZScGRD?= =?utf-8?B?dTl1YjZHNlcybi9qckpkdXlPMU1XTG5IM2h5ak91SDhqL3gxN25NRTB3Ni9i?= =?utf-8?B?Ly80Vzk5V1Vsckx5TjF0LzBHTUZlR2xaNGN3MXRHek1nU2RHcmFRZEk2RlhF?= =?utf-8?B?azgzUFQyRGZWL2VEbHFyRUdnNjlxMkdYZy95bzAwNkVwbnRaNHNBSGxBT2V0?= =?utf-8?B?amt6a0w2RllhY244ajFRcmJEaEwxK2NpNStpbXFWb2JIMlpLcWlJaDlxZEw2?= =?utf-8?Q?5FyWc/5uuucijifgG/CPZxNcdQkyB/fZ64FeQtV?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB3860.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3e8dbd4c-c6c8-4c69-a6f4-08d92443d1b9
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2021 14:53:14.8390 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: AJjVdU3BYOAyr/hteQBq9eOMEEr40W1QRF8iNV+0R8k/FylVFlMWnZRO4xZZ2Gg4Pn1Sxx5Pjxrzc/AR4iYlDK4vS4tgTsk4BZxSgvZTUIo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4019
Archived-At: 
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 May 2021 14:53:30 -0000

SGkgVGltLA0KDQo+MSkgWW91IGFyZSBjb3JyZWN0IHRoYXQgdGhlIHBhcmFtZXRlcnMgYXJlIGRl
c2NyaWJpbmcgd2hhdCB0aGUgc2VuZGVyIHdpbGwgYmUgdXNpbmcgaW4gdGhlIHBheWxvYWQgKHN0
cmljdGx5IHNwZWFraW5nIHRoZXNlIGFyZSBub3QgY2FwYWJpbGl0aWVzLCBidXQgcmF0aGVyIHN0
cmljdCBwYXlsb2FkIHNldHRpbmdzIHRoYXQgd2lsbCBiZSBob25vcmVkKS4gDQoNCkZhaXIgZW5v
dWdoLiBQZXJoYXBzICJzZW5kaW5nIHByb3BlcnRpZXMiPw0KDQo+VGhlIHJlY2VpdmVyIHNob3Vs
ZCBiZSBhYmxlIHRvIGhhbmRsZSBzdWNoIHNldHRpbmdzIChhcyBkZXNjcmliZWQgYnkgdGhlc2Ug
cGFyYW1ldGVycykuDQo+SSB3aWxsIGFkanVzdCB0aGF0IHBhcnQgdG8gcmVmbGVjdCB3aGF0IHlv
dSBwcm9wb3NlLg0KPg0KPjIpIEkgd2lsbCBpbmRlZWQgcmVwbGFjZSBjcmVhdG9yL3JlY2VpdmVy
IGJ5IG9mZmVyb3IvYW5zd2VyZXIgcmVzcGVjdGl2ZWx5LiBBcyBmb3IgdGhlIGFuc3dlcmVyOiBv
biBhY2NlcHRpbmcgdGhlIGNvbm5lY3Rpb24gd2l0aCB0aGUgb2ZmZXJlZCBwYXJhbWV0ZXJzLCB0
aGVyZSBpcyBub3QgbXVjaCB0byBzZW5kIGJhY2sgdy5yLnQuIHBhcmFtZXRlcnMuIA0KPkJ1dCBm
b3IgZWFzeSBvZiByZWNvZ25pemluZyB0aGUgbmVnb3RpYXRlZCBzdHJlYW0sIHdlIGJlbGlldmUg
dGhlIGFuc3dlcmVyIHNob3VsZCB1c2UgdGhlIHNhbWUgZm10cCAoYXMgZ2l2ZW4gaW4gdGhlIG9m
ZmVyKSBpbiBpdHMgYW5zd2VyLg0KDQpEb2VzIHRoYXQgYWxzbyBpbmNsdWRlIHRoZSBhY3R1YWwg
cGF5bG9hZCB0eXBlIG51bWJlciB2YWx1ZT8NCg0KPlNvLCB1cGRhdGVkIHRleHQgd291bGQgYmVj
b21lOg0KDQpJdCBsb29rcyBvaywgYnV0IEkgc3VnZ2VzdCB0byBjaGFuZ2U6DQoNCiJvZmZlcm9y
IG9mIHRoZSBzZXNzaW9uIiAtPiAib2ZmZXJlciINCg0KImFuc3dlcmluZyBhcHBsaWNhdGlvbiIg
LT4gImFuc3dlcmVyIg0KDQouLi5iZWNhdXNlIHRoYXQgaXMgdGhlIHRlcm1pbm9sb2d5IHdlIHVz
ZSB0byBpZGVudGl0eSB0aGUgZW50aXRpZXMgd2hlbiB0YWxraW5nIGFib3V0IG9mZmVyIGFuZCBh
bnN3ZXIuDQoNCkFsc28sIEkgZ3Vlc3MgeW91IHNob3VsZCBzYXkgIlNIQUxMIHJlcGx5IHdpdGgg
dGhlIGV4YWN0IHNhbWUgcGFyYW1ldGVyIFZBTFVFUyBpbiB0aGUuLi4iLg0KDQpSZWdhcmRzLA0K
DQpDaHJpc3Rlcg0KDQoNCg0KLy8tLS0gU05JUFBFVA0KOC4yLiAgVXNhZ2Ugd2l0aCBTRFAgT2Zm
ZXIvQW5zd2VyIE1vZGVsDQoNCiAgIFdoZW4gSlBFRyBYUyBpcyBvZmZlcmVkIG92ZXIgUlRQIHVz
aW5nIFNEUCBpbiBhbiBvZmZlci9hbnN3ZXIgbW9kZWwNCiAgIFtSRkMzMjY0XSBmb3IgbmVnb3Rp
YXRpb24gZm9yIHVuaWNhc3QgdXNhZ2UsIHRoZSBmb2xsb3dpbmcNCiAgIGxpbWl0YXRpb25zIGFu
ZCBydWxlcyBhcHBseToNCg0KICAgICAgVGhlICJhPWZtdHAiIGF0dHJpYnV0ZSBTSEFMTCBiZSBw
cmVzZW50IHNwZWNpZnlpbmcgdGhlIHJlcXVpcmVkDQogICAgICBwYXJhbWV0ZXIgInRyYW5zbW9k
ZSIgYW5kIE1BWSBzcGVjaWZ5IGFueSBvZiB0aGUgb3B0aW9uYWwNCiAgICAgIHBhcmFtZXRlcnMs
IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDcuMS4NCg0KICAgICAgQWxsIHBhcmFtZXRlcnMgaW4g
dGhlICJhPWZtdHAiIGF0dHJpYnV0ZSBpbmRpY2F0ZSBzZW5kaW5nDQogICAgICBjYXBhYmlsaXRp
ZXMgKGkuZS4gcHJvcGVydGllcyBvZiB0aGUgcGF5bG9hZCkuDQoNCiAgICAgIEFuIGFuc3dlcmVy
IG9mIHRoZSBTRFAgaXMgcmVxdWlyZWQgdG8gc3VwcG9ydCBhbGwgcGFyYW1ldGVycyBhbmQNCiAg
ICAgIHZhbHVlcyBvZiB0aGUgcGFyYW1ldGVycyBwcm92aWRlZCBieSB0aGUgb2ZmZXJvcjsgb3Ro
ZXJ3aXNlLCB0aGUNCiAgICAgIGFuc3dlcmVyIFNIQUxMIHJlamVjdCB0aGUgc2Vzc2lvbi4gIEl0
IGZhbGxzIG9uIHRoZSBvZmZlcm9yIG9mIHRoZQ0KICAgICAgc2Vzc2lvbiB0byB1c2UgdmFsdWVz
IHRoYXQgYXJlIGV4cGVjdGVkIHRvIGJlIHN1cHBvcnRlZCBieSB0aGUNCiAgICAgIGFuc3dlcmlu
ZyBhcHBsaWNhdGlvbi4gIElmIHRoZSBhbnN3ZXJlciBhY2NlcHRzIHRoZSBzZXNzaW9uLCBpdA0K
ICAgICAgU0hBTEwgcmVwbHkgd2l0aCB0aGUgZXhhY3Qgc2FtZSBwYXJhbWV0ZXJzIGluIHRoZSAi
YT1mbXRwIg0KICAgICAgYXR0cmlidXRlIGFzIGl0IHdhcyBvZmZlcmVkLg0KLy8tLS0gU05JUFBF
VA0KDQoNCklmIHlvdSBiZWxpZXZlIHRoaXMgaXMgb2ssIEkgd2lsbCBwb3N0IGFuIHVwZGF0ZWQg
ZHJhZnQgdG8gdGhlIGRhdGF0cmFja2VyLg0KDQpCZXN0IHJlZ2FyZHMsDQpUaW0uDQoNCg0KLS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rl
ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpTZW50OiBNb25kYXkgMzEgTWF5IDIwMjEgMTY6MTAN
ClRvOiBUaW0gQnJ1eWxhbnRzIDxUQlJAaW50b3BpeC5jb20+OyBUaG9tYXMgUmljaHRlciA8dGhv
bWFzLnJpY2h0ZXJAaWlzLmZyYXVuaG9mZXIuZGU+OyBhdnRAaWV0Zi5vcmcNCkNjOiBKZWFuLUJh
cHRpc3RlIExvcmVudCA8amIubG9yZW50QGludG9waXguY29tPg0KU3ViamVjdDogUkU6IFtBVlRD
T1JFXSBTRFAgZGlyZWN0b3JhdGUgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtanBl
Z3hzLTEzDQoNCkhpIFRpbSwNCg0KPkJlZm9yZSBJIHVwbG9hZCBhIG5ldyBkcmFmdCB0byBhZGRy
ZXNzIHRoZSBTRFAsIEkgd291bGQgbGlrZSB5b3UgdG8gcmV2aXNlIHRoZSBmb2xsb3dpbmcgdGV4
dC4NCj4NCj5BcyB5b3Ugc3RhdGVkLCB3aGVuIGRlc2NyaWJpbmcgdGhlIFNEUCBvZmZlci9hbnN3
ZXIgbW9kZWwsIHRoZSBkcmFmdCBuZWVkcyB0byBhZGRyZXNzIHRoZSA1IGZvbGxvd2luZyB0b3Bp
Y3M6DQo+WC4xIEdlbmVyaWMgU0RQIENvbnNpZGVyYXRpb25zDQo+WC4yLiAgR2VuZXJhdGluZyB0
aGUgSW5pdGlhbCBTRFAgT2ZmZXINCj5YLjMuICBHZW5lcmF0aW5nIHRoZSBTRFAgQW5zd2VyDQo+
WC40LiAgT2ZmZXJlciBQcm9jZXNzaW5nIG9mIHRoZSBTRFAgQW5zd2VyIFguNS4gIE1vZGlmeWlu
ZyB0aGUgU2Vzc2lvbg0KPg0KPk91ciBxdWVzdGlvbjogSXMgdGhpcyBzdWZmaWNpZW50bHkgZGVz
Y3JpYmVkIGluIFJGQzMyNjQgYW5kIGlzIGl0IG9rIHRvIHJlZmVyIHRvIHRoYXQgUkZDIHdpdGgg
c29tZSBleHRyYSBjbGFyaWZpY2F0aW9ucz8gUkZDMzI2NCBzZWVtcyB0byBiZSB3aGF0IHdlIGlu
dGVuZCAiaWYiIHNkcCBvZmZlci9hbnN3ZXIgaXMgdXNlZC4gVGhpcyB3b3VsZCByZXN1bHQgaW4g
dGhlIGZvbGxvd2luZyB0ZXh0Og0KPg0KPi8vLS0tIFNOSVBQRVQNCj44LjIuICBVc2FnZSB3aXRo
IFNEUCBPZmZlci9BbnN3ZXIgTW9kZWwNCj4NCj4gICBXaGVuIEpQRUcgWFMgaXMgb2ZmZXJlZCBv
dmVyIFJUUCB1c2luZyBTRFAgaW4gYW4gb2ZmZXIvYW5zd2VyIG1vZGVsDQo+ICAgW1JGQzMyNjRd
IGZvciBuZWdvdGlhdGlvbiBmb3IgdW5pY2FzdCB1c2FnZSwgdGhlIGZvbGxvd2luZw0KPiAgIGxp
bWl0YXRpb25zIGFuZCBydWxlcyBhcHBseToNCj4NCj4gICAgICBUaGUgImE9Zm10cCIgYXR0cmli
dXRlIFNIQUxMIGJlIHByZXNlbnQgc3BlY2lmeWluZyB0aGUgcmVxdWlyZWQNCj4gICAgICBwYXJh
bWV0ZXIgInRyYW5zbW9kZSIgYW5kIE1BWSBzcGVjaWZ5IGFueSBvZiB0aGUNCj4gICAgICBvcHRp
b25hbCBwYXJhbWV0ZXJzLCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA3LjEuDQo+DQo+ICAgICAg
QWxsIHBheWxvYWQgcGFyYW1ldGVycyBhcmUgZGVjbGFyYXRpdmUsIG1lYW5pbmcgdGhhdCB0aGV5
IGRlc2NyaWJlDQo+ICAgICAgcHJvcGVydGllcyBvZiB0aGUgcGF5bG9hZC4NCj4NCj4gICAgICBB
IHJlY2VpdmVyIG9mIHRoZSBTRFAgaXMgcmVxdWlyZWQgdG8gc3VwcG9ydCBhbGwgcGFyYW1ldGVy
cyBhbmQNCj4gICAgICB2YWx1ZXMgb2YgdGhlIHBhcmFtZXRlcnMgcHJvdmlkZWQ7IG90aGVyd2lz
ZSwgdGhlIHJlY2VpdmVyIFNIQUxMDQo+ICAgICAgcmVqZWN0IHRoZSBzZXNzaW9uLiAgSXQgZmFs
bHMgb24gdGhlIGNyZWF0b3Igb2YgdGhlIHNlc3Npb24gdG8gdXNlDQo+ICAgICAgdmFsdWVzIHRo
YXQgYXJlIGV4cGVjdGVkIHRvIGJlIHN1cHBvcnRlZCBieSB0aGUgcmVjZWl2aW5nDQo+ICAgICAg
YXBwbGljYXRpb24uDQo+Ly8tLS0gU05JUFBFVA0KPg0KPiBGZWVkYmFjayB3b3VsZCBiZSB2ZXJ5
IHdlbGNvbWUuDQoNCkEgY291cGxlIG9mIGNvbW1lbnRzOg0KDQoNClExOg0KDQoiQWxsIHBheWxv
YWQgcGFyYW1ldGVycyBhcmUgZGVjbGFyYXRpdmUsIG1lYW5pbmcgdGhhdCB0aGV5IGRlc2NyaWJl
IHByb3BlcnRpZXMgb2YgdGhlIHBheWxvYWQuIg0KDQpJIGRvbid0IHRoaW5rIHlvdSBuZWVkIHRv
IHNheSB0aGF0Lg0KDQpCYXNlZCBvbiBvdXIgZWFybGllciBkaXNjdXNzaW9ucywgSSB0aGluayB3
aGF0IHlvdSBuZWVkIHRvIHBvaW50IG91dCBpcyB0aGF0IHRoZSBmbXRwIGF0dHJpYnV0ZSBpcyB1
c2VkIHRvIGluZGljYXRlIFNFTkRJTkcgY2FwYWJpbGl0aWVzLg0KDQotLS0tDQoNClEyOg0KDQoi
QSByZWNlaXZlciBvZiB0aGUgU0RQIGlzIHJlcXVpcmVkIHRvIHN1cHBvcnQgYWxsIHBhcmFtZXRl
cnMgYW5kIHZhbHVlcyBvZiB0aGUgcGFyYW1ldGVycyBwcm92aWRlZDsgb3RoZXJ3aXNlLCB0aGUg
cmVjZWl2ZXIgU0hBTEwgcmVqZWN0IHRoZSBzZXNzaW9uLiAgSXQgZmFsbHMgb24gdGhlIGNyZWF0
b3Igb2YgdGhlIHNlc3Npb24gdG8gdXNlIHZhbHVlcyB0aGF0IGFyZSBleHBlY3RlZCB0byBiZSBz
dXBwb3J0ZWQgYnkgdGhlIHJlY2VpdmluZyBhcHBsaWNhdGlvbi4iDQoNCkluc3RlYWQgb2YgInJl
Y2VpdmVyIiwgSSB3b3VsZCBzYXkgYW5zd2VyZXIuDQoNCkluc3RlYWQgb2YgImNyZWF0b3IiLCBJ
IHdvdWxkIHNheSBvZmZlcmVyLg0KDQpBbHNvLCBhc3N1bWluZyB0aGUgYW5zd2VyZXIvcmVjZWl2
ZXIgYWNjZXB0cyB0aGUgb2ZmZXIsIHRoZXJlIGlzIG5vIHRleHQgb24gd2hhdCBpdCBpbmNsdWRl
cyBpbiB0aGUgYW5zd2VyLiBEb2VzIHRoZSBhbnN3ZXJlciBhbHNvIGluY2x1ZGUgYW4gZm10cCBh
dHRyaWJ1dGU/IElmIHNvLCB3aGF0IHZhbHVlcyBkb2VzIGl0IGluY2x1ZGU/DQoNClJlZ2FyZHMs
DQoNCkNocmlzdGVyDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBh
dnQgPGF2dC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgVGltIEJydXlsYW50cw0KU2Vu
dDogRnJpZGF5IDI4IE1heSAyMDIxIDEyOjIxDQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlz
dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT47IFRob21hcyBSaWNodGVyIDxodHRwczovL3VybGRl
ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fdGhvbWFzLnJpY2h0ZXItNDBp
aXMuZnJhdW5ob2Zlci5kZSZkPUR3SUdhUSZjPWV1R1pzdGNhVERsbHZpbUVOOGI3alhyd3FPZi12
NUFfQ2RwZ25WZmlpTU0mcj1MVHhVR3VrTENFZkVVZG9fYnEwNDhRJm09UHZJS25veTJJUk1SX1p5
alFHRGZYb0ZBdVpaSlZ1MkxFYTM3Q0hHbGlHMCZzPWdMXzkxaHd3MkN0ZmhTQ2FRcmJKVHViVU8x
S2Vjak50RkZfdzlXT1JENWcmZT0+OyBhdnRAaWV0Zi5vcmcNCkNjOiBKZWFuLUJhcHRpc3RlIExv
cmVudCA8amIubG9yZW50QGludG9waXguY29tPg0KU3ViamVjdDogUmU6IFtBVlRDT1JFXSBTRFAg
ZGlyZWN0b3JhdGUgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtanBlZ3hzLTEzDQoN
CkhpIENocmlzdGVyLA0KDQpUaGFua3MgZm9yIHRoZSBxdWljayByZXNwb25zZSwgd2UgcmVhbGx5
IGFwcHJlY2lhdGUgeW91ciB0aW1lLg0KDQpTbywgbGV0IG1lIGVsYWJvcmF0ZSBhIGJpdDoNCg0K
Pj4gRmlyc3QsIHJlZ2FyZGluZyBSRkMgODQ1MCwgdGhhdCBzcGVjaWZpY2F0aW9uIHdhcyBwcm9i
YWJseSBuZXZlciByZXZpZXdlZCBieSB0aGUgU0RQIGRpcmVjdG9yYXRlLCBzbyBJIGNhbid0IHJl
YWxseSBjb21tZW50IG9uIHRoYXQuIEJ1dCwgSSBzZWUgdGhhdCB0aGUgUkZDIGUuZy4sIHNheXMg
bm90aGluZyBhYm91dCB3aGV0aGVyIHRoZSBTRFAgaW5kaWNhdGVzIHNlbmRpbmcgb3IgcmVjZWl2
aW5nIGNhcGFiaWxpdGllcy4NCg0KT2ssIEkgdW5kZXJzdGFuZCB0aGF0IFJGQyA4NDUwIG1pZ2h0
IG5vdCBiZSBlbnRpcmVseSBjbGVhciBvciB3ZWxsIHdyaXR0ZW4gb24gdGhlIFNEUCBwYXJ0Lg0K
DQo+PiBTZWNvbmQsIG5vYm9keSBtYW5kYXRlcyB5b3UgdG8gdXNlIFNEUCwgYW5kIG1vc3QgcGFy
dCBvZiB0aGUgc3BlYyBpcyBwcm90b2NvbCBpbmRlcGVuZGVudC4gQnV0LCB0aGUgIlNEUCBPZmZl
ci9BbnN3ZXIiIHNlY3Rpb24gZGVzY3JpYmVzIHRoZSBTRFAgb2ZmZXIvYW5zd2VyIHByb2NlZHVy
ZXMsICpJRiogeW91IGNob29zZSB0byB1c2UgdGhhdCBtZWNoYW5pc20gZm9yIG5lZ290aWF0aW5n
IHRoZSBzZXNzaW9uLg0KDQpPay4gVGhhdCBJIHVuZGVyc3RhbmQuIEluIG91ciBjYXNlLCBTRFAg
YXMgdGhlIHNlc3Npb24gcHJvdG9jb2wgaXMgbm90IGNyaXRpY2FsLCBidXQgc3RpbGwgYSBuaWNl
IHRvIGhhdmUuIERvIHlvdSBhZ3JlZT8gT3IgZG8geW91IHJlY29tbWVuZCB3ZSByZW1vdmUgdGhl
IFNEUCBvZmZlci9hbnN3ZXIgc2VjdGlvbj8NCg0KV2hhdCB3ZSBkbyBuZWVkIHRvIHNheSBpcyBo
b3cgdG8gbWFwIHBhcmFtZXRlcnMgaW50byBhbiBTRFAtY29tcGxpYW50IGZvcm1hdCBkZXNjcmlw
dGlvbiwgZm9yIHRoZSBzYW1lIHJlYXNvbnMgYXMgUkZDIDg0NTAgYW5kIG1hbnkgb3RoZXIgdmlk
ZW8gcGF5bG9hZCBSRkMncyAoVlA4LCBWUDksIEguMjY0L0FWQywgSC4yNjUvSEVWQywgZXRjKS4g
VGhpcyBhbGxvd3MgdXNpbmcgbWFueSBvdGhlciBzZXNzaW9uIG5lZ290aWF0aW9uIHByb3RvY29s
cyB0aGF0IHJlbHkgb24gdGhlIFNEUCBkZXNjcmlwdGlvbi4NCg0KPj4gVGhpcmQgLi4uLg0KDQpJ
IGJlbGlldmUgd2hhdCBpcyB2ZXJ5IGltcG9ydGFudCB0byBleHBsYWluIGlzIHRoYXQgYWxsIG9m
IG91ciBwYXJhbWV0ZXJzIGFyZSBkZWNsYXJhdGl2ZSwgbWVhbmluZyB0aGF0IHRoZXkgZGVzY3Jp
YmUgZXhhY3QgYml0c3RyZWFtIHByb3BlcnRpZXMsIGFuZCBub3QgcmVjZWl2ZXIgY2FwYWJpbGl0
aWVzLiBUaGUgU0RQIHBhcmFtZXRlcnMgY2FuIGJlIHVzZWQgdG8gY29tbXVuaWNhdGUgYmV0d2Vl
biBzZW5kZXIvcmVjZWl2ZXIgd2hhdCB0aGV5IHdpc2ggdG8gZXhjaGFuZ2UgYmVmb3JlIHNlbmRp
bmcgYWN0dWFsIHBheWxvYWQsIGJ1dCBub25lIG9mIHRoZXNlIHBhcmFtZXRlcnMgb3IgdmFsdWVz
IGFyZSAiZG93bmdyYWRhYmxlIiBvciAiaW5jbHVzaXZlIGNhcGFiaWxpdHkgc2V0cyIuIFhTIGRv
ZXMgbm90IGhhdmUgc3VjaCBjb25jZXB0cywgYXMgaXQgaXMgYSBsb3ctY29tcGxleGl0eSBjb2Rl
YywgaW50ZW5kZWQgcHJpbWFyaWx5IHRvIHJlcGxhY2UgdW5jb21wcmVzc2VkIHZpZGVvIHN0cmVh
bXMuDQoNClNvbWVob3csIHRoaXMgcmFpc2VzIHRoZSBmb2xsb3dpbmc6DQoNClguMSBHZW5lcmlj
IFNEUCBDb25zaWRlcmF0aW9ucw0KICBJIGJlbGlldmUgaGVyZSB3ZSBleHBsYWluIHRoYXQgcGFy
YW1ldGVycyBhcmUgZGVjbGFyYXRpdmUgYW5kIHJlcHJlc2VudCBiaXRzdHJlYW0vcGF5bG9hZCB2
YWx1ZXMvc2V0dGluZ3MuIFNvIGJvdGggc2lkZXMgY2FuIHVzZSB0aGVzZSB0byBpbmRpY2F0ZSB3
aGF0IHRoZSBwYXlsb2FkIHdpbGwgbG9vayBsaWtlLg0KDQpYLjIuICBHZW5lcmF0aW5nIHRoZSBJ
bml0aWFsIFNEUCBPZmZlcg0KICBOb3QgbXVjaCB0byBzYXkgaGVyZS4gQXMgSSB1bmRlcnN0YW5k
IGFuIFNEUCBzZXNzaW9uIGNhbiBiZSBpbml0aWF0ZWQgZnJvbSBlaXRoZXIgcmVjZWl2ZXIgb3Ig
c2VuZGVyIHNpZGVzPyBTbywgdGhleSBqdXN0IHNlbmQgYSB2YWxpZCBtZWRpYSBkZXNjcmlwdGlv
biBvZiB0aGUgY29udGVudCB0aGV5IHdhbnQgdG8gZXhjaGFuZ2UuIElmIGVpdGhlciBzaWRlIGNh
bm5vdCBoYW5kbGUgY2VydGFpbiBwYXlsb2FkIHNldHRpbmdzLCB0aGVuIGl0IHNob3VsZCByZWpl
Y3QgdGhlIG9mZmVyIChvciBhbnN3ZXIpLiBBbiBvZmZlcmVyIGp1c3Qgc2VuZHMgd2hhdCBpdCB3
YW50cyB0byByZWNlaXZlIG9yIHNlbmQuDQoNClguMy4gIEdlbmVyYXRpbmcgdGhlIFNEUCBBbnN3
ZXINCiAgSSBkb24ndCB0aGluayB0aGVyZSBpcyBhbnl0aGluZyBzcGVjaWFsIHRvIG1lbnRpb24g
aGVyZT8gVGhlIGFuc3dlcmVyIHRha2VzIHRoZSBkZWNsYXJhdGl2ZSBwYXJhbWV0ZXJzIGFuZCBl
aXRoZXIgYWNjZXB0cyBvciByZWplY3RzIHRoZSBzZXNzaW9uLiBJdCBzaG91bGQgTk9UIG1vZGlm
eSB0aGUgb2ZmZXIgaW4gYW55IHdheS4NCg0KWC40LiAgT2ZmZXJlciBQcm9jZXNzaW5nIG9mIHRo
ZSBTRFAgQW5zd2VyDQogIEkgZG9uJ3QgdGhpbmsgdGhlcmUgaXMgYW55dGhpbmcgc3BlY2lhbCB0
byBtZW50aW9uIGhlcmU/IElmIHRoZSBhbnN3ZXIgYWNjZXB0ZWQgdGhlIG9mZmVyLCB0aGVuIHRo
ZSBzdHJlYW0gY2FuIHN0YXJ0Lg0KDQpYLjUuICBNb2RpZnlpbmcgdGhlIFNlc3Npb24NCiAgTW9k
aWZ5aW5nIHRoZSBzZXNzaW9uIGlzIHBvc3NpYmxlLCBidXQgdGhpcyBpcyB2ZXJ5IGltcGxlbWVu
dGF0aW9uIHNwZWNpZmljLiBCYXNpY2FsbHksIG1vZGlmeWluZyBhIHNlc3Npb24gaXMgdmVyeSBz
aW1pbGFyIHRvIGNyZWF0aW9uIG9mIGEgbmV3IHNlc3Npb24uIEJvdGggc2lkZXMgc2hvdWxkIGFn
cmVlIG9uIHRoZSBwYXlsb2FkIHRoZXkgd2lsbCBleGNoYW5nZS4NCg0KDQpJJ20gc29ycnkgdG8g
ZHJhZyB0aGlzIG91dCwgYnV0IEkgdGhpbmsgdGhhdCBoYXZpbmcgdGhpcyBjb252ZXJzYXRpb24g
YnkgZW1haWwgaXMgbW9yZSBlZmZpY2llbnQgdGhhbiBwb3N0aW5nIGRyYWZ0cyDwn5iKIEkgYXBw
cmVjaWF0ZSB5b3VyIGZlZWRiYWNrLg0KDQpUaW0uDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS0NCkZyb206IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv
bi5jb20+DQpTZW50OiBGcmlkYXkgMjggTWF5IDIwMjEgMTA6MzkNClRvOiBUaW0gQnJ1eWxhbnRz
IDxUQlJAaW50b3BpeC5jb20+OyBUaG9tYXMgUmljaHRlciA8aHR0cHM6Ly91cmxkZWZlbnNlLnBy
b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3Rob21hcy5yaWNodGVyLTQwaWlzLmZyYXVu
aG9mZXIuZGUmZD1Ed0lHYVEmYz1ldUdac3RjYVREbGx2aW1FTjhiN2pYcndxT2YtdjVBX0NkcGdu
VmZpaU1NJnI9TFR4VUd1a0xDRWZFVWRvX2JxMDQ4USZtPVZ2c2E3dUZBNXowRFduQlNvTkVudmFf
NGlqNXJiY1FHT3dMcF9pLTN6N3cmcz1hdWVKaW9UbHRZMDVreGZCMjFSRk92U1FzejhsdWxUb3lY
UXpiY3RKQ3ZjJmU9PjsgYXZ0QGlldGYub3JnDQpDYzogSmVhbi1CYXB0aXN0ZSBMb3JlbnQgPGpi
LmxvcmVudEBpbnRvcGl4LmNvbT4NClN1YmplY3Q6IFJFOiBbQVZUQ09SRV0gU0RQIGRpcmVjdG9y
YXRlIHJldmlldyBvZiBkcmFmdC1pZXRmLXBheWxvYWQtcnRwLWpwZWd4cy0xMw0KDQpIaSwNCg0K
Rmlyc3QsIHJlZ2FyZGluZyBSRkMgODQ1MCwgdGhhdCBzcGVjaWZpY2F0aW9uIHdhcyBwcm9iYWJs
eSBuZXZlciByZXZpZXdlZCBieSB0aGUgU0RQIGRpcmVjdG9yYXRlLCBzbyBJIGNhbid0IHJlYWxs
eSBjb21tZW50IG9uIHRoYXQuIEJ1dCwgSSBzZWUgdGhhdCB0aGUgUkZDIGUuZy4sIHNheXMgbm90
aGluZyBhYm91dCB3aGV0aGVyIHRoZSBTRFAgaW5kaWNhdGVzIHNlbmRpbmcgb3IgcmVjZWl2aW5n
IGNhcGFiaWxpdGllcy4NCg0KU2Vjb25kLCBub2JvZHkgbWFuZGF0ZXMgeW91IHRvIHVzZSBTRFAs
IGFuZCBtb3N0IHBhcnQgb2YgdGhlIHNwZWMgaXMgcHJvdG9jb2wgaW5kZXBlbmRlbnQuIEJ1dCwg
dGhlICJTRFAgT2ZmZXIvQW5zd2VyIiBzZWN0aW9uIGRlc2NyaWJlcyB0aGUgU0RQIG9mZmVyL2Fu
c3dlciBwcm9jZWR1cmVzLCAqSUYqIHlvdSBjaG9vc2UgdG8gdXNlIHRoYXQgbWVjaGFuaXNtIGZv
ciBuZWdvdGlhdGluZyB0aGUgc2Vzc2lvbi4NCg0KVGhpcmQsIEkgZG9uJ3QgdGhpbmsgeW91IG5l
ZWQgdmVyeSBtdWNoIHRleHQuIFRoZSBpbXBvcnRhbnQgdGhpbmcgaXMgdG8gc2F5IHdoYXQgaXMg
cGxhY2VkIGluIG9mZmVycyBhbmQgYW5zd2Vycywgd2hldGhlciB0aGVyZSBhcmUgY29uc3RyYWlu
dHMgd2hlbiBnZW5lcmF0aW5nIHRoZSBhbnN3ZXIsIGFuZCB3aGV0aGVyIHRoZXJlIGFyZSBjb25z
dHJhaW50cyB3aGVuIGl0IGNvbWVzIHRvIG1vZGlmeWluZyB0aGUgc2Vzc2lvbi4gQW5kLCB5b3Ug
ZG8gTk9UICBuZWVkIHRvIHNwZWNpZnkgSE9XIHRvIG1vZGlmeSBhIHNlc3Npb24sIGJ1dCB3aGV0
aGVyIHRoZXJlIGFyZSBwYXlsb2FkLXNwZWNpZmljIGNvbnN0cmFpbnRzIHdoZW4gZG9pbmcuDQoN
ClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t
OiBUaW0gQnJ1eWxhbnRzIDxUQlJAaW50b3BpeC5jb20+DQpTZW50OiBwZXJqYW50YWkgMjguIHRv
dWtva3V1dGEgMjAyMSA5LjQ5DQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1i
ZXJnQGVyaWNzc29uLmNvbT47IFRob21hcyBSaWNodGVyIDxodHRwczovL3VybGRlZmVuc2UucHJv
b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fdGhvbWFzLnJpY2h0ZXItNDBpaXMuZnJhdW5o
b2Zlci5kZSZkPUR3SUZBZyZjPWV1R1pzdGNhVERsbHZpbUVOOGI3alhyd3FPZi12NUFfQ2RwZ25W
ZmlpTU0mcj1MVHhVR3VrTENFZkVVZG9fYnEwNDhRJm09Z2ZCNFBGLXZWQlctSFZ4Y1N4Q3gwN0xD
aFExQ1NlcFlOM0pudXZQWnZoZyZzPVdnMDhpMzIxM2JDeVAwWWI4SGo1aWhwQldqLWRsclZuS0Rk
amdnT0picUEmZT0+OyBhdnRAaWV0Zi5vcmcNCkNjOiBKZWFuLUJhcHRpc3RlIExvcmVudCA8amIu
bG9yZW50QGludG9waXguY29tPg0KU3ViamVjdDogUkU6IFtBVlRDT1JFXSBTRFAgZGlyZWN0b3Jh
dGUgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtanBlZ3hzLTEzDQoNCkhpIENocmlz
dGVyLA0KDQpJJ20gYSBsaXR0bGUgYml0IHN0dWNrIGluIGhvdyB0byByZXNvbHZlIGFuZCBhZGRy
ZXNzIHlvdXIgY29tbWVudHMuIE9uIG9uZSBoYW5kIEkgdW5kZXJzdGFuZCB0aGF0IHdlIHdhbnQg
dGhlIHRleHQgdG8gYmUgY2xlYXIsIGJ1dCBvbiB0aGUgb3RoZXIgaGFuZCB3ZSBkbyBub3Qgd2Fu
dCB0byByZXBlYXQgU0RQIHNwZWNpZmljcyB0b28gbXVjaC4gU0RQIGlzIGp1c3Qgb25lIHdheSB0
byBuZWdvdGlhdGUgYSBzZXNzaW9uLCBhbmQgaW4gdGhlIGNhc2Ugb2YgWFMgaXQgaXMgbm90IHRo
ZSBtb3N0IGNvbW1vbmx5IHVzZWQgb25lLiBYUyBpcyBub3QgcmVhbGx5IGludGVuZGVkIGZvciB0
aGUgY2xhc3NpY2FsIHZpZGVvLWNhbGwgY2FzZSwgYnV0IHJhdGhlciB0byBzdHJlYW0gaGlnaC1x
dWFsaXR5IHZpZGVvIGNvbnRlbnQgaW4gYSBwcm9mZXNzaW9uYWwgZW52aXJvbm1lbnQuIEl0IGNh
biBiZSB1c2VkIGZvciB2aWRlbyBjb25mZXJlbmNpbmcsIGJ1dCBiZXR0ZXIgc3VpdGVkIGNvZGVj
cyBleGlzdCBmb3IgdGhhdCB1c2UtY2FzZS4NCg0KSG93ZXZlciwgd2hhdCBpcyBpbXBvcnRhbnQg
dG8gbGF5IG91dCBjb3JyZWN0bHkgaXMgdGhlIG1hcHBpbmcgb2YgdGhlIG1lZGlhIHBhcmFtZXRl
cnMgaW50byB0aGUgYT1mbXRwIGZpZWxkIG9mIFNEUCwgYmVjYXVzZSB0aGlzIGlzIGFjdHVhbGx5
IHVzZWQgYnkgbWFueSBvdGhlciBwcm90b2NvbHMgKHNvLCBqdXN0IHRoZSBtZWRpYSBkZXNjcmlw
dGlvbiBwYXJ0IG9mIFNEUCBpcyB1c2VkKS4NCg0KT3JpZ2luYWxseSwgd2UgYmFzZWQgb3VyIGRy
YWZ0IHRleHQgb24gUkZDIDg0NTAgKFZDLTIgSFEgUlRQIFBheWxvYWQpLiBJbiB0aGF0IHJlc3Bl
Y3QsIHdoYXQgaXMgd3JpdHRlbiB0aGVyZSBraW5kIG9mIGZpdHMgZXhhY3RseSB3aGF0IHdlIHdh
bnQgd2l0aCBYUy4gR2l2ZW4gdGhhdCB0aGlzIGlzIGEgcHVibGlzaGVkIFJGQywgd2UgYXJlIHB1
enplbGVkIGEgYml0IGFzIHRvIHdoeSBvdXIgZHJhZnQgd291bGQgbmVlZCB0byBlbGFib3JhdGUg
c28gZXh0ZW5zaXZlbHkgb24gU0RQLiBGb3Igc3VyZSwgd2UnZCBsaWtlIHRvIGFsbG93IFNEUCBv
ZmZlci9hbnN3ZXIgbmVnb3RpYXRpb24gd2l0aCBYUy4gQnV0IHRoaXMgaXMgdmVyeSBzaW1wbGU6
IGVhY2ggc2lkZSB0ZWxscyB0aGUgb3RoZXIgc2lkZSB3aGF0IGl0IHN1cHBvcnRzLCBhbmQgdGhh
dCdzIGl0LiBJbiBYUyB0aGUgcGFyYW1ldGVycyBhcmUgZGVjbGFyYXRpdmUsIG1lYW5pbmcgKGF0
IGxlYXN0IHRoYXQncyB3aGF0IHdlIHdhbnQgdG8gZXhwcmVzcykgdGhhdCBlYWNoIHBhcmFtZXRl
ciBpcyByZXByZXNlbnRzIGFuIGV4YWN0IHZhbHVlIGFuZCBpcyBub3QgImluY2x1c2l2ZSIgaW50
byBhIHJhbmdlIG9mIGxlc3NlciB2YWx1ZXMuIEluIG90aGVyIHdvcmRzLCB0aGUgb3RoZXIgc2lk
ZSBjYW5ub3QgZXhwZWN0IHRoYXQgYSAibGVzc2VyIiB2YWx1ZSBvZiBhIHBhcmFtZXRlciBjYW4g
d29yay4NCg0KWW91ciBwcm9wb3NlZCBzdHJ1Y3R1cmUgaXMganVzdCB0byBlbGFib3JhdGUgYW5k
IG91dCBvZiBzY29wZS4gQXMgc3VjaCwgSSB3b3VsZCBhc2sgeW91IHRvIGNvbnNpZGVyIHRoZSBl
eGFtcGxlIG9mIFJGQyA4NDUwICh3aGVyZSB0aGUgdXNlLWNhc2UgYW5kIHB1cnBvc2UgbWF0Y2hl
cyB0aGF0IG9mIG91ciBkcmFmdCkuIEZvciBleGFtcGxlOiBXaHkgZG8gd2UgbmVlZCB0byBzdGF0
ZSBhbnl0aGluZyBzcGVjaWZpYyBvbiAiTW9kaWZ5aW5nIHRoZSBTZXNzaW9uIj8gSXNuJ3QgdGhp
cyBsYXllZCBvdXQgYnkgU0RQIG9uIGhvdyB0byBtb2RpZnkgYSBzZXNzaW9uPyBUaGVyZSdzIG5v
dGhpbmcgc3BlY2lmaWMgdG8gYmUgcHV0IGluIG91ciBkcmFmdCAod2UgZG8gbm90IHdhbnQgdG8g
cHJldmVudCwgbm90IHN1Z2dlc3QgdGhpcyBmdW5jdGlvbmFsaXR5KS4NCg0KSSBob3BlIHlvdSBj
YW4gdW5kZXJzdGFuZCBvdXIgZGlmZmljdWx0eSB3aXRoIHlvdXIgcmVtYXJrcyBhbmQgY29tbWVu
dHMuIE91ciBwcm9wb3NhbCBhcyBzdWNoIGlzIHRvIGtlZXAgdGhlIHRleHQgYWJvdXQgU0RQIHZl
cnkgc2hvcnQgYW5kIHNpbXBsZS4gVGhlIFJUUCBQYXlsb2FkIGRyYWZ0IGNhbiBiZSB1c2VkIHdp
dGggU0RQLCBidXQgaXQncyBjZXJ0YWlubHkgbm90IHRoZSBvbmx5IHdheS4NCg0KSSB3aWxsIGJl
IHByZXBhcmluZyBhbiB1cGRhdGVkIGRyYWZ0IHdoaWNoIHRyaWVzIHRvIGJlIHZlcnkgbWluaW1h
bCBvbiB0aGUgU0RQIHNwZWNpZmljcy4gVW5sZXNzIGFueXRoaW5nIGlzIHRlY2huaWNhbGx5IHdy
b25nLCBJIHJlYWxseSBob3BlIHlvdSBjYW4gYWdyZWUgdG8gaXQgYW5kIG1vdmUgZm9yd2FyZCB3
aXRoIHRoZSBwdWJsaWNhdGlvbiBwcm9jZXNzLg0KDQpCZXN0IHJlZ2FyZHMsDQpUaW0uDQoNCg0K
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGF2dCA8YXZ0LWJvdW5jZXNAaWV0Zi5v
cmc+IE9uIEJlaGFsZiBPZiBDaHJpc3RlciBIb2xtYmVyZw0KU2VudDogV2VkbmVzZGF5IDI2IE1h
eSAyMDIxIDE4OjQzDQpUbzogVGhvbWFzIFJpY2h0ZXIgPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v
ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX190aG9tYXMucmljaHRlci00MGlpcy5mcmF1bmhv
ZmVyLmRlJmQ9RHdJRkFnJmM9ZXVHWnN0Y2FURGxsdmltRU44YjdqWHJ3cU9mLXY1QV9DZHBnblZm
aWlNTSZyPUxUeFVHdWtMQ0VmRVVkb19icTA0OFEmbT1nZkI0UEYtdlZCVy1IVnhjU3hDeDA3TENo
UTFDU2VwWU4zSm51dlBadmhnJnM9V2cwOGkzMjEzYkN5UDBZYjhIajVpaHBCV2otZGxyVm5LRGRq
Z2dPSmJxQSZlPT47IGF2dEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtBVlRDT1JFXSBTRFAgZGly
ZWN0b3JhdGUgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtanBlZ3hzLTEzDQoNClRo
aXMgaXMgYSBzdHJ1Y3R1cmUgdGhhdCBpcyB0eXBpY2FsbHkgdXNlZCBmb3IgU0RQIG9mZmVyL2Fu
c3dlciBwcm9jZWR1cmVzOg0KDQpYLiAgU0RQIE9mZmVyL0Fuc3dlciBQcm9jZWR1cmVzDQogICAg
IFguMS4gIEdlbmVyaWMgU0RQIENvbnNpZGVyYXRpb25zDQoJPEhlcmUgeW91IGNhbiBkZXNjcmli
ZSB0aGluZ3Mgd2hpY2ggYXBwbHkgdG8gYm90aCBvZmZlcnMgYW5kIGFuc3dlcnM+DQogICAgIFgu
Mi4gIEdlbmVyYXRpbmcgdGhlIEluaXRpYWwgU0RQIE9mZmVyDQoJPEhlcmUgeW91IGRlc2NyaWJl
IGhvdyB0aGUgaW5pdGlhbCBTRFAgb2ZmZXIgZm9yIHRoZSBzZXNzaW9uIGlzIGdlbmVyYXRlZD4N
CiAgICAgWC4zLiAgR2VuZXJhdGluZyB0aGUgU0RQIEFuc3dlcg0KCTxIZXJlIHlvdSBkZXNjcmli
ZSBob3cgdGhlIGFuc3dlcmVyIGdlbmVyYXRlcyB0aGUgU0RQIGFuc3dlciwgaW5jbHVkaW5nIHdo
ZXRoZXIgcGFyYW1ldGVycy9wYXJhbWV0ZXIgdmFsdWVzIG5lZWQgdG8gYmUgYSBzdWJzZXQgb2Yg
dGhlIHBhcmFtZXRlcnMvcGFyYW1ldGVyIHZhbHVlcyBpbiB0aGUgb2ZmZXIgZXRjPg0KICAgICBY
LjQuICBPZmZlcmVyIFByb2Nlc3Npbmcgb2YgdGhlIFNEUCBBbnN3ZXINCiAgICAgNy41LiAgTW9k
aWZ5aW5nIHRoZSBTZXNzaW9uDQoJPEhlcmUgeW91IGRlc2NyaWJlIGNvbnN0cmFpbnRzIHJlbGF0
ZWQgdG8gbW9kaWZpY2F0aW9uIG9mIHRoZSBzZXNzaW9uLCBpbmNsdWRpbmcgd2hldGhlciB0aGVy
ZSBhcmUgY2VydGFpbiBwYXJhbWV0ZXJzL3BhcmFtZXRlciB2YWx1ZXMgdGhhdCB5b3UgY2Fubm90
IG1vZGlmeSBldGM+DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCi0tLS0tT3JpZ2luYWwgTWVz
c2FnZS0tLS0tDQpGcm9tOiBhdnQgPGF2dC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2Yg
Q2hyaXN0ZXIgSG9sbWJlcmcNClNlbnQ6IGtlc2tpdmlpa2tvIDI2LiB0b3Vrb2t1dXRhIDIwMjEg
MTkuMzgNClRvOiBUaG9tYXMgUmljaHRlciA8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu
Y29tL3YyL3VybD91PWh0dHAtM0FfX3Rob21hcy5yaWNodGVyLTQwaWlzLmZyYXVuaG9mZXIuZGUm
ZD1Ed0lDQWcmYz1ldUdac3RjYVREbGx2aW1FTjhiN2pYcndxT2YtdjVBX0NkcGduVmZpaU1NJnI9
TFR4VUd1a0xDRWZFVWRvX2JxMDQ4USZtPUx0ZWZRaUxoZHJYd1V5Y2FoN1ptc2F5a19kdEhGLWhN
RUJ3SG82RHBldDAmcz0tVE8xUWY3bDFfcWM0a2xSS3ZidVc4X2VENEw4Zjg1T0I1RGFoYjJMUUdF
JmU9PjsgYXZ0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0FWVENPUkVdIFNEUCBkaXJlY3RvcmF0
ZSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1qcGVneHMtMTMNCg0KSGksDQoNCj4+
IFVuZm9ydHVuYXRlbHkgSSBkb24ndCB0aGluayB3aGF0IHlvdSBleHBsYWluIGFib3ZlIGlzIHZl
cnkgY2xlYXIgaW4gDQo+PiB0aGUgdGV4dC4NCj4+IA0KPj4gQ29uc2lkZXIgdGhlIGZvbGxvd2lu
Zy4NCj4+IA0KPj4gVGhlIG9mZmVyZXIgc2VuZHMgYW4gb2ZmZXIuIFRoZSBvZmZlcmVyIHNwZWNp
ZmllcyB0aGUgY2hhcmFjdGVyaXN0aWNzIA0KPj4gdGhhdCB0aGUgb2ZmZXJlciB3YW50cyB0byBy
ZWNlaXZlLiBTaW1pbGFybHksIHRoZSBhbnN3ZXIgc3BlY2lmaWVzIA0KPj4gdGhlIGNoYXJhY3Rl
cmlzdGljcyB0aGF0IHRoZSBhbnN3ZXJlciB3YW50cyB0byByZWNlaXZlIC0gdGhlIGFuc3dlcmVy
IA0KPj4gZG9lcyBOT1Qgc3BlY2lmeSB3aGF0IGl0IGlzIGdvaW5nIHRvIHNlbmQuIHdoaWNoIEkg
dGhpbmsgdGhlIHRleHQgaXMgDQo+PiBjdXJyZW50bHkgZGVzY3JpYmluZy4NCj4NCj4gU29ycnkg
dG8gc291bmQgY29uZnVzZWQsIGJ1dCBtYXliZSB5b3UgY291bGQgZXhwbGFpbiBhIGJpdCBiZXR0
ZXIuIFRvIG15IHVuZGVyc3RhbmRpbmcsIGl0IGlzIHRoZSBvZmZlcmVyIHRoYXQgZGVzY3JpYmVz
IHdoYXQgaXQgb2ZmZXJzIHRvIHNlbmQsIGFuZCBub3QgdGhlIG90aGVyIHdheSBhcm91bmQ/IA0K
PiBNYXliZSBJIG1pc3VuZGVyc3RhbmQgc29tZXRoaW5nIHZlcnkgZnVuZGFtZW50YWw/IFNvcnJ5
IHRvIGFzayB0aGVzZSBlbGVtZW50YXJ5IHF1ZXN0aW9ucywgYnV0IHRoaXMgaXMgaW1wb3J0YW50
IGZvciB0aGUgdGV4dC4NCg0KSW4gU0RQIE9mZmVyL0Fuc3dlciwgdGhlIGRlZmF1bHQgaXMgdG8g
aW5kaWNhdGUgd2hhdCB5b3UgYXJlIHdpbGxpbmcgdG8gUkVDRUlWRSA6KQ0KDQpUeXBpY2FsbHkg
eW91ciByZWNlaXZpbmcgY2FwYWJpbGl0aWVzIGFsc28gaW1wbGljaXRseSBpbmRpY2F0ZSB3aGF0
IHlvdSBhcmUgYWJsZSB0byBzZW5kLiBGb3IgZXhhbXBsZSwgaWYgSSBhbSBpbmRpY2F0aW5nIHRo
YXQgSSBhbSB3aWxsaW5nIHRvIHJlY2VpdmUgY29kZWMgWCBpdCBub3JtYWxseSBtZWFucyB0aGF0
IEkgYW0gYWxzbyBhYmxlIHRvIHNlbmQgY29kZWMgWC4NCg0KIEJ1dCwgdGhlcmUgYXJlIGNhc2Vz
IHdoZXJlIHRoYXQgaXMgbm90IHRydWUsIGVzcGVjaWFsbHkgd2hlbiBpdCBjb21lcyB0byB2aWRl
byBjb2RlcyB3aGVyZSB5b3UgdHlwaWNhbGx5IGhhdmUgbW9yZSBwYXJhbWV0ZXJzIGFzc29jaWF0
ZWQgd2l0aCB0aGUgY29kZWMsIGFuZCBvbmUgbmVlZHMgdG8gZXhwbGljaXRseSBpbmRpY2F0ZSBz
ZW5kaW5nIGNhcGFiaWxpdGllcy4gDQoNCi0tLQ0KDQo+PiAiVGhlIHJlY2VpdmVyIFNIQUxMIGln
bm9yZSBhbnkgdW5yZWNvZ25pemVkIHBhcmFtZXRlciBvciBpbnZhbGlkIA0KPj4gcGFyYW1ldGVy
IHZhbHVlLiINCj4+IA0KPj4gRmlyc3QsIEluIG15IG9waW5pb24gaW52YWxpZCBwYXJhbWV0ZXJz
IHZhbHVlcyBzaGFsbCB0cmlnZ2VyIGFuIGVycm9yLg0KPj4gDQo+PiBTZWNvbmQsIHdoYXQgaXMg
YW4gdW5yZWNvZ25pemVkIHBhcmFtZXRlcj8NCj4NCj4gSSB3b25kZXIgd2h5IHdlIG5lZWQgdG8g
c3BlY2lmeSB0aGlzLCBpLmUuIHdoYXQgYSByZWNlaXZlIGRvZXMgYWJvdXQgDQo+IHBhcmFtZXRl
cnMgaXQgZG9lcyBub3QgcmVjb2duaXplPyBFc3NlbnRpYWxseSwgdGhpcyBpcyBhIHByb2JsZW0g
b2YgDQo+ICJmb3Jld2FyZCBjb21wYXRpYmlsaXR5Ii4gV291bGRuJ3QgaXQgYmUgYSBtYXR0ZXIg
b2YgaW1wbGVtZW50YXRpb24gd2hldGhlciB0aGUgcmVjZWl2ZXIgYWNjZXB0cyBhbiBvZmZlciAo
bm90ZSB3ZWxsLCB0aGUgcmVjZWl2ZXIpLCBhbmQgYXR0ZW1wdHMgdG8gZGVjb2RlIGEgc3RyZWFt
IG9uIGEgImJlc3QgZWZmb3J0IiBiYXNpcywga2VlcGluZyBpbiBtaW5kIHRoYXQgdGhlIHN0cmVh
bSBpdHNlbGYgaW5jbHVkZXMgYWRkaXRpb25hbCBtZWFucyB0byBpZGVudGlmeSByZXF1aXJlZCBj
YXBhYmlsaXRpZXMgbmVjZXNzYXJ5IGZvciBhIHN1Y2Nlc3NmdWwgZGVjb2RlLg0KPg0KPiBJZiB0
aGF0IGlzIG5vdCBhbiBvcHRpb24sIHdlIHdvdWxkL2NvdWxkIG5lZWQgbWVhbnMgdG8gaWRlbnRp
ZnkgdGhlIA0KPiB0eXBlIG9mIHBhcmFtZXRlcnMgaW4gYSBmb3Jld2FyZCBjb21wYXRpYmxlIHdh
eS4gSS5lLiwgY29udmVudGlvbnMgYnkgd2hpY2ggd2Ugd291bGQgaWRlbnRpZnkgaW4gdGhlIGZ1
dHVyZSBwYXJhbWV0ZXJzIGEgcmVjZWl2ZXIgY2FuIHNhZmVseSBpZ25vcmUgYW5kIGF0dGVtcHQg
dG8gZGVjb2RlLCBhbmQgcGFyYW1ldGVycyBhIHJlY2VpdmVyIGNhbm5vdCBzYWZlbHkgaWdub3Jl
Lg0KDQpJIHRoaW5rIGl0IGlzIGZpbmUgdG8gc2F5IHRoYXQgdW5yZWNvZ25pemVkIHBhcmFtZXRl
cnMgc2hhbGwgYmUgaWdub3JlZC4gSXQgaXMgdGhlbiB1cCB0byBmdXR1cmUgc3BlY2lmaWNhdGlv
bnMgdG8gd29ycnkgYWJvdXQgYmFja3dhcmQgY29tcGF0aWJpbGl0eSwgcmF0aGVyIHRoYW4gdGhp
cyBzcGVjaWZpY2F0aW9uIHdvcnJ5aW5nIGFib3V0IGZvcndhcmQgY29tcGF0aWJpbGl0eS4NCg0K
Pj4gQWxzbywgdGhlIHRleHQgZG9lcyBub3Qgc2F5IHdoYXQgcmVzdHJpY3Rpb25zIChpZiBhbnkp
IHRoZXJlIGFyZSB3aGVuIA0KPj4gaXQgY29tZXMgdG8gbW9kaWZ5IHRoZSBzdHJlYW0gZHVyaW5n
IGEgc2Vzc2lvbi4gSXMgaXQgYWxsb3dlZCB0byANCj4+IG1vZGlmeSBhbnkvYWxsIGNoYXJhY3Rl
cmlzdGljcz8NCj4NCj4gTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHlvdSBjYW5ub3QgbW9kaWZ5
IGNoYXJhY3RlcmlzdGljcyBkdXJpbmcgYSANCj4gc2Vzc2lvbi4gSWYgeW91IG5lZWQgdG8gbW9k
aWZ5LCB5b3UgbmVlZCB0byBzZXR1cCBhIG5ldyBzZXNzaW9uIGFuZCANCj4gY2FuY2VsIHRoZSBj
dXJyZW50IG9uZS4gRm9yIEpQRUcgWFMgc3RyZWFtIGRlY29kZXJzLCBvbmUgY2Fubm90IGV4cGVj
dCB0aGF0IGFuIGluc3RhbmNpYXRlZCBkZWNvZGVyIGNhbiBkZWNvZGUgZnJvbSBtb2RpZmllZCBw
YXJhbWV0ZXJzIGluIG1pZC1zdHJlYW0gbGV2ZWwuIFRoYXQgaXMsIGlmIHlvdSBzdGFydCBkZWNv
ZGluZyBpbiBmdWxsLUhELCBhbmQgdGhlbiBzdHJlYW0gcGFyYW1ldGVycyBiZWNvbWUgOEssIHRo
ZSBkZWNvZGVyIHdpbGwgaGF2ZSB0byBhYm9ydC4NCg0KVGhlc2Uga2luZCBvZiB0aGluZ3MgbmVl
ZCB0byBiZSBzcGVjaWZpZWQuIEkgZG9uJ3QgdGhpbmsgaXQgbmVlZHMgdG8gYmUgZm9yYmlkZGVu
IHRvIHRyeSB0byBtb2RpZnkgc29tZXRoaW5nLCBiZWNhdXNlIHRoZXJlIGNvdWxkIGJlIHRleHQg
dGhhdCBzdHJvbmdseSByZWNvbW1lbmRzIGFnYWluc3QgZG9pbmcgaXQuDQoNClJlZ2FyZHMsDQoN
CkNocmlzdGVyDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQpBdWRpby9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KYXZ0QGlldGYub3Jn
DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3
dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2F2dCZkPUR3SUNBZyZjPWV1R1pzdGNhVERsbHZp
bUVOOGI3alhyd3FPZi12NUFfQ2RwZ25WZmlpTU0mcj1MVHhVR3VrTENFZkVVZG9fYnEwNDhRJm09
THRlZlFpTGhkclh3VXljYWg3Wm1zYXlrX2R0SEYtaE1FQndIbzZEcGV0MCZzPTF2WlR1RmpJLVFi
ZXhQNW9YOXBnYTM1ZFpaenRoWEdnbjdTOFpnb2Q5TEUmZT0NCg0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3Jl
IE1haW50ZW5hbmNlDQphdnRAaWV0Zi5vcmcNCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50
LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fYXZ0
JmQ9RHdJQ0FnJmM9ZXVHWnN0Y2FURGxsdmltRU44YjdqWHJ3cU9mLXY1QV9DZHBnblZmaWlNTSZy
PUxUeFVHdWtMQ0VmRVVkb19icTA0OFEmbT1MdGVmUWlMaGRyWHdVeWNhaDdabXNheWtfZHRIRi1o
TUVCd0hvNkRwZXQwJnM9MXZaVHVGakktUWJleFA1b1g5cGdhMzVkWlp6dGhYR2duN1M4WmdvZDlM
RSZlPQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkF1
ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQphdnRAaWV0Zi5vcmcNCmh0dHBz
Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYu
b3JnX21haWxtYW5fbGlzdGluZm9fYXZ0JmQ9RHdJR2FRJmM9ZXVHWnN0Y2FURGxsdmltRU44Yjdq
WHJ3cU9mLXY1QV9DZHBnblZmaWlNTSZyPUxUeFVHdWtMQ0VmRVVkb19icTA0OFEmbT1WdnNhN3VG
QTV6MERXbkJTb05FbnZhXzRpajVyYmNRR093THBfaS0zejd3JnM9b2lMMnBkbDdoXzZMVlktNEU4
OGhWVkkxTm9EV3M2akJPTGIxcldyQV9uSSZlPQ0K


From nobody Mon May 31 09:16:46 2021
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 401A13A1D62 for ; Mon, 31 May 2021 09:16:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=intopix.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8Yt14YJO1Jv for ; Mon, 31 May 2021 09:16:40 -0700 (PDT)
Received: from dispatch1-eu1.ppe-hosted.com (dispatch1-eu1.ppe-hosted.com [185.183.29.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C77473A1D63 for ; Mon, 31 May 2021 09:16:39 -0700 (PDT)
X-Virus-Scanned: Proofpoint Essentials engine
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04lp2053.outbound.protection.outlook.com [104.47.14.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1-eu1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id BE3FC7C0067; Mon, 31 May 2021 16:16:35 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ehf2vG5Jw0cbDnLqCJnFUtCSKc468/nYtl2t4Ytzd1oe/qSg+LkKoPtEUnc+xNK6vgVOGOfmUy8BmBcykEbOKCxXoCq8wWBoylORAaN+9xVleGTNr2wD1PPwSebcy2h6XFzNU67t476U3V7pB8NivUP79K5pJatpQKFq7rBBnkwDymxK6y4sjjXj526xtORU9cW2pspG7IkDymTkx4uD32Nxjf8yiV18NPgnktr+xvRwCUnrbkT2ECPqGzCbBdMCCNglgcKN5tf2ErIVrN+SzU9qEsx534boEdMkDGjRkfeYdA5iL92i7zNyNkkzoaUo+wn8SHwyB+DS2f9eMxw12w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cEmxp3hpjrkFAXDhMe43TD0ZNdZN84Pld+mEBmyWCwM=; b=TQ+U7agWb/eiq6Cs81dtxGfVAJ8g6qecfJKGQJgqiTF8F2BaJ8/blyFO5JdqQAqWEmaP7kp/cr9MUQ8IAU5gzGWOhOTHkkx8gvGBoE6IwJxjs16Er1DcwhNDqSun0ZcbvtknSOC/2HuWPVWd5PP+/wXARYjETlmI4Q3U4tDB/tHscWT3e8/JchqUGurKoSY1g/vyZHLA+NsLlt/EuwAyzA+WbL2PwTod4n3jGLKfl8KqNXWBQe3KaddOIXUURaqEFGrToyDUOfLXk+HHYIfSf3ITuszZOh/UmRWGhMWDOe0V4GBMwPALIMJAdWWb1UvFtNs1dLgffrec/1GP41m8tw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intopix.com; dmarc=pass action=none header.from=intopix.com; dkim=pass header.d=intopix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intopix.onmicrosoft.com; s=selector1-intopix-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cEmxp3hpjrkFAXDhMe43TD0ZNdZN84Pld+mEBmyWCwM=; b=WaxLNnT/QNpbPOn3EwZifdaJcaDAroq/eSJdGTAVpaCVKkFJ3+0iE4bEyM8WUxjOcEpMhtoPFIR/6bTcTCVEb0RuLS2JTd1tLCoh6YHCpG8wKzU5c5xEyPlPkd02daUa0yfJEoL4ZOZBqZXdiUJN1r9I5rCLlEQpqpI8yU5VEeU=
Received: from PR3P192MB0748.EURP192.PROD.OUTLOOK.COM (2603:10a6:102:4f::24) by PR3P192MB0730.EURP192.PROD.OUTLOOK.COM (2603:10a6:102:4f::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.22; Mon, 31 May 2021 16:16:34 +0000
Received: from PR3P192MB0748.EURP192.PROD.OUTLOOK.COM ([fe80::8ab:c06a:c2cf:b0ac]) by PR3P192MB0748.EURP192.PROD.OUTLOOK.COM ([fe80::8ab:c06a:c2cf:b0ac%9]) with mapi id 15.20.4173.030; Mon, 31 May 2021 16:16:33 +0000
From: Tim Bruylants 
To: Christer Holmberg , Thomas Richter , "avt@ietf.org" 
CC: Jean-Baptiste Lorent 
Thread-Topic: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
Thread-Index: AddLKBOH9HzaEV4jTtmQ8TPYzmKsqwFVwo+gABfRKwAAFpWSgABEymJQAABwR+AAT0NxwAAES3xQAAEQhVAAkqc4oAAOiNkwAACTaHAAASFDQAAC8bWg
Date: Mon, 31 May 2021 16:16:33 +0000
Message-ID: 
References:    <7aa5e890-47c5-cdb7-5657-26864cec3d4c@iis.fraunhofer.de>         
In-Reply-To: 
Accept-Language: en-US, nl-NL
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=intopix.com;
x-originating-ip: [94.227.86.241]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4113271d-dddf-4ac6-0b4b-08d9244f7556
x-ms-traffictypediagnostic: PR3P192MB0730:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: +ldxLMuife5yw/NvXkJUMgIvSNTahBwIvj7sEgt80qSahpQigZqqlNBY7jzRjvGjfEHAz/kQ79vxLtveV+OsSyQMQORxsJmgfb9TsXcaIWhCOOlvC6K/ks9qhxZMpv1Ku1XBR48RUoGoUSsyKI7ON01tGgzA40YJmpKHeaD1ACfEetJ+cod1nHnHeqctnPqK72Awl1KJV5XrArw9h4VzoRhc3EXhwZpvIkaacezt93ECJb31jR+6jGKRAiAqOvyL0AwbRmsrePZcD7CtgXcS1r/qZa/F/uXTCg0DOwUSY2+vK9BfpRGkfWEDKVwdRUCymG+L4i4/38aLZygvNzaNfZPkZvD+prMUAUxc5k/DtKzLe3RBkXmiUZ5Hih2S+kmP0DTzQptjWKRtCXPC9Qy/xe/zaz0HBzGUJ4CC/v8eX9AbJoYbo1toLJ1QrmEJWT2ptG+HcglkFkVIBPlr6vaDJYAFj2pAKjgUDKmxQK3GFc2VVdZC0rXfTTHEnJFsYEDw8l4cmnxpD9L2g3a9a/AdlPFIAX8vGzBrh/MYLjH5kIIwa2S8in4HkwvkYKuIVoCv/Wz+lqJPdVu6mis/IH7OsK/EsgVHww6lc9xxly33aF5Zyh35wghxZswQdo6RD3ADSVU+0TPrb3PFzGi+jZVEhlrV3OVIHiuN4FYJmY5THpMsZSfgJx8jlZ7Jv8ruGWfGXO3Q8ddbSL7rk5If65iVKuRoocqEY9R99zjmW2SSmKw=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:PR3P192MB0748.EURP192.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFS:(376002)(366004)(136003)(396003)(39830400003)(346002)(966005)(478600001)(76116006)(8936002)(8676002)(5660300002)(186003)(66476007)(66946007)(64756008)(7696005)(107886003)(2906002)(83380400001)(66446008)(52536014)(55016002)(53546011)(9686003)(316002)(38100700002)(30864003)(71200400001)(110136005)(122000001)(6506007)(66556008)(26005)(4326008)(86362001)(33656002)(579004); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?utf-8?B?c09FbFh0MTNJSXY3UDJSU2N6N1VLN2FuOVdEY2RMM3luR1dsbGM5WTl3WWw4?= =?utf-8?B?SVNTSnBGOTVHcnVITE9tQXB1YUVHM0ViRWRMUTRIeEh5ZWpiTFd3Qk55dkY0?= =?utf-8?B?UmxKS2RPMVgxaFlhcEw2bms0OXMrOTh0bEZYZkoxMmx6bzRhQkpjMWtLc1RP?= =?utf-8?B?OHUxZEpSYnFBOUdqbGZMRVdTdytaVmhmQ3Q5eC9RRmVUOVk1TEd3K1pTeUJn?= =?utf-8?B?cVNWakZTMGVreGl5bDRwV2N4TUliN1UxY0VHcnRoR2dnTGhYQmRpN2wxdDdF?= =?utf-8?B?aWlWcDkxQWRUQUJJb2sybXdTL3hLUEhTYlpXTVpDQWlROUxJVWhzalhyVWo1?= =?utf-8?B?VlRwUlk4djNxZ1NGa2FBNDd2WGZRVmVQb0xGWk9oZXhLRXpRazFsSCtpbkRP?= =?utf-8?B?NHFTS09XM1YxMXVBYlFFZVhmc2FWZXlHK21rUDZGaG1IbnV2V0RKeEtKOUpS?= =?utf-8?B?Rm1xMFBzSGxaSGtGbkdWSTFDeVFXZFc4UFBveGpDaXV3SlNtRHVzc1NXaDBO?= =?utf-8?B?c1JJWUNpUnB4UGtrWE9HSjZyYWtyZU9HRStsNndmby8yVk96bG13V2NkNTJ6?= =?utf-8?B?TnQwd1hBdWpnTDhaeHNGeE5DVUhLRzRPZVBuK0ExYU9CdDF0ZG51a2JhNkNs?= =?utf-8?B?Mnd5M20vOGFNTS8vNUhMMXhjclVSQkFXaXZIVFdkcEpUckF0RlhXY0llRkxv?= =?utf-8?B?WHpuUXlPdzBPQ3E2dE1nb1hBaDlZVWk1MHRiS3lJU3k0RFY3N0xyMnBkeGxH?= =?utf-8?B?SldoalNUOUlZMmw1TFl3SU85OVBKaHo2WjZuVlNSdVh0cDdmam1aVGZIazBZ?= =?utf-8?B?SWZSWXdzMkpCVFprZ2Rmd3FOMHJab0I3UHlYNGFIS3B3bTdObzd0aStpR1FP?= =?utf-8?B?d1poRUxCa253S1JyQktVek4rc2J0bDJqYmlGc0djM2dkbmFzNVBRbm9QQVI4?= =?utf-8?B?TDZjN2YrL1FVUEJxOW42YUVFaTF0Ymt6ajRTWEFWWFFUU3Fvb05sc2x5S2Fq?= =?utf-8?B?Q3JlbHhtQ2V0UTM5VmtlZXBWUVMxaVdlSVo1V2lVWTFEc1NQL3BTVVd1TTI1?= =?utf-8?B?bmtpcXNtV2k0RG9HZ3EzR09QaGF5ODd1eGJGa2VpSzhodHRYbzVrRUhGOS9S?= =?utf-8?B?cUVCR01XUHZyaWZpOWUxcDA0cEw5WWxjZFZQcGJrSmExUjJLd2lDWVVyL3JX?= =?utf-8?B?UUhFQ3Q2aE5yV2s4T2s0R0w1UU9wQjUrWU13VWplQ0pQaXR6dVFSMXFuQkwz?= =?utf-8?B?NElZaVc3ditqNjhaN0tHQXQyZGNmM3k1aTB1REhIbE5YNmgzajhsZVdyclI1?= =?utf-8?B?b0RaRDlROXBvTFBGQnNtVUxHcXR4VGlTbFRvTlZtc2QybkNWd2wwWjlUMTRS?= =?utf-8?B?ZWFlWE9wcjhpaDlxNGI2eFhtWHNuKzgra1NoTisrWmcrV200TEdLTVFtTXEv?= =?utf-8?B?S2gza3hTR3FUWEVNN1h1bzZBN2dFUFFKTDlXdFZQTjRBYzJGenVYdkZQZ05X?= =?utf-8?B?TkNWdXRpdGVKTlQyNENMWS8xUzdTZnJ1N0gzQjd2RjBUT2dLWGZxOVJQY2NS?= =?utf-8?B?WFpsTUxrRjkzOVBjRjc4N2lHSjY2RUVGbUpxYmpjVXhmK1VJS0tWVDA1UWVv?= =?utf-8?B?Z1VUakFtQzlVVFZ3T3U3UmIrVlAvYjVMMXgyeFdCMHRDamtlRlRhYTNKMzBl?= =?utf-8?B?V1JCdlNKdW10WjFBN3ZxWE9nVmZXVk90RHRDeEQ1Ti9wSGgwSE1QYW9McFVI?= =?utf-8?Q?aKEla9SiHhMhv6O/qSEB5fcI0uS11yAdGSjMEoU?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: intopix.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PR3P192MB0748.EURP192.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 4113271d-dddf-4ac6-0b4b-08d9244f7556
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2021 16:16:33.7254 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5f9168c7-cdac-4b23-9509-c278399e3c1f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: hEKBVqNqrH9YQbUR0174Nzakbn0kfIDMm72m7jRseLt+kEqnDaJq1RI+ENzZRV7i
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3P192MB0730
X-MDID: 1622477797-gbId8Ulz7Xco
Archived-At: 
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 May 2021 16:16:45 -0000

SGkgQ2hyaXN0ZXIsDQoNCjEpIEkgYmVsaWV2ZSAiLi4uIHNlbmRpbmcgY2FwYWJpbGl0aWVzIChp
LmUuIHByb3BlcnRpZXMgb2YgdGhlIHBheWxvYWQpLi4uIiBpcyBjb3JyZWN0Lg0KDQoyYSkgSSdt
IG5vdCAxMDAlIHN1cmUgdGhhdCBJIHVuZGVyc3RhbmQgd2hhdCB5b3UgbWVhbiBieSB0aGlzLiBO
b3JtYWxseSBJIHdvdWxkIGFzc3VtZSB0aGF0IHRoZSBzYW1lIHBheWxvYWQgdHlwZSBpcyB0byBi
ZSB1c2VkIGluIGFuIGFuc3dlciAodG8gc2ltcGxpZnkgdGhpbmdzKS4gQWxsdGhvdWdoIGluIFJG
QzMyNjQgdGhpcyBpcyBhIFNIT1VMRCBhbmQgbm90IGEgTVVTVC4gU28sIEkgYWRkZWQgYSBzZW50
ZW5jZSB0byBhbHNvIHJlY29tbWVuZCB0aGlzLg0KDQoyYikgSSBtYWRlIHRoZSBzdWdnZXN0ZWQg
Y2hhbmdlcyAob2ZmZXJlci9hbnN3ZXJlcikuIEl0IGlzIGdvb2QgdG8gZm9sbG93IGNvbW1vbiB0
ZXJtaW5vbG9neS4gSSBhbHNvIGFncmVlIGFib3V0IHRoZSBWQUxVRVMgKEkgd2FzIGluIGRvdWJ0
IHdoZW4gd3JpdGluZyB0aGF0IHNlbnRlbmNlIGFib3V0IHRoaXMsIHNvIGl0J3MgZ29vZCB0aGF0
IHlvdSBtZW50aW9uIHRoaXMpLg0KDQovLy0tLSBTTklQUEVUDQo4LjIuICBVc2FnZSB3aXRoIFNE
UCBPZmZlci9BbnN3ZXIgTW9kZWwNCg0KICAgV2hlbiBKUEVHIFhTIGlzIG9mZmVyZWQgb3ZlciBS
VFAgdXNpbmcgU0RQIGluIGFuIG9mZmVyL2Fuc3dlciBtb2RlbA0KICAgW1JGQzMyNjRdIGZvciBu
ZWdvdGlhdGlvbiBmb3IgdW5pY2FzdCB1c2FnZSwgdGhlIGZvbGxvd2luZw0KICAgbGltaXRhdGlv
bnMgYW5kIHJ1bGVzIGFwcGx5Og0KDQogICAgICBUaGUgImE9Zm10cCIgYXR0cmlidXRlIFNIQUxM
IGJlIHByZXNlbnQgc3BlY2lmeWluZyB0aGUgcmVxdWlyZWQNCiAgICAgIHBhcmFtZXRlciAidHJh
bnNtb2RlIiBhbmQgTUFZIHNwZWNpZnkgYW55IG9mIHRoZSBvcHRpb25hbA0KICAgICAgcGFyYW1l
dGVycywgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNy4xLg0KDQogICAgICBBbGwgcGFyYW1ldGVy
cyBpbiB0aGUgImE9Zm10cCIgYXR0cmlidXRlIGluZGljYXRlIHNlbmRpbmcNCiAgICAgIGNhcGFi
aWxpdGllcyAoaS5lLiBwcm9wZXJ0aWVzIG9mIHRoZSBwYXlsb2FkKS4NCg0KICAgICAgQW4gYW5z
d2VyZXIgb2YgdGhlIFNEUCBpcyByZXF1aXJlZCB0byBzdXBwb3J0IGFsbCBwYXJhbWV0ZXJzIGFu
ZA0KICAgICAgdmFsdWVzIG9mIHRoZSBwYXJhbWV0ZXJzIHByb3ZpZGVkIGJ5IHRoZSBvZmZlcmVy
OyBvdGhlcndpc2UsIHRoZQ0KICAgICAgYW5zd2VyZXIgU0hBTEwgcmVqZWN0IHRoZSBzZXNzaW9u
LiAgSXQgZmFsbHMgb24gdGhlIG9mZmVyZXIgdG8gdXNlDQogICAgICB2YWx1ZXMgdGhhdCBhcmUg
ZXhwZWN0ZWQgdG8gYmUgc3VwcG9ydGVkIGJ5IHRoZSBhbnN3ZXJlci4gIElmIHRoZQ0KICAgICAg
YW5zd2VyZXIgYWNjZXB0cyB0aGUgc2Vzc2lvbiwgaXQgU0hBTEwgcmVwbHkgd2l0aCB0aGUgZXhh
Y3Qgc2FtZQ0KICAgICAgcGFyYW1ldGVycyB2YWx1ZXMgaW4gdGhlICJhPWZtdHAiIGF0dHJpYnV0
ZSBhcyBpdCB3YXMgb2ZmZXJlZC4NCg0KICAgICAgVGhlIHNhbWUgUlRQIHBheWxvYWQgdHlwZSBu
dW1iZXIgdXNlZCBpbiB0aGUgb2ZmZXIgU0hPVUxEIGJlDQogICAgICB1c2VkIGluIHRoZSBhbnN3
ZXIsIGFzIHNwZWNpZmllZCBpbiBbUkZDMzI2NF0uDQovLy0tLSBTTklQUEVUDQoNCg0KQmVzdCBy
ZWdhcmRzLA0KVGltLg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENo
cmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IA0KU2VudDog
TW9uZGF5IDMxIE1heSAyMDIxIDE2OjUzDQpUbzogVGltIEJydXlsYW50cyA8VEJSQGludG9waXgu
Y29tPjsgVGhvbWFzIFJpY2h0ZXIgPHRob21hcy5yaWNodGVyQGlpcy5mcmF1bmhvZmVyLmRlPjsg
YXZ0QGlldGYub3JnDQpDYzogSmVhbi1CYXB0aXN0ZSBMb3JlbnQgPGpiLmxvcmVudEBpbnRvcGl4
LmNvbT4NClN1YmplY3Q6IFJFOiBbQVZUQ09SRV0gU0RQIGRpcmVjdG9yYXRlIHJldmlldyBvZiBk
cmFmdC1pZXRmLXBheWxvYWQtcnRwLWpwZWd4cy0xMw0KDQpIaSBUaW0sDQoNCj4xKSBZb3UgYXJl
IGNvcnJlY3QgdGhhdCB0aGUgcGFyYW1ldGVycyBhcmUgZGVzY3JpYmluZyB3aGF0IHRoZSBzZW5k
ZXIgd2lsbCBiZSB1c2luZyBpbiB0aGUgcGF5bG9hZCAoc3RyaWN0bHkgc3BlYWtpbmcgdGhlc2Ug
YXJlIG5vdCBjYXBhYmlsaXRpZXMsIGJ1dCByYXRoZXIgc3RyaWN0IHBheWxvYWQgc2V0dGluZ3Mg
dGhhdCB3aWxsIGJlIGhvbm9yZWQpLiANCg0KRmFpciBlbm91Z2guIFBlcmhhcHMgInNlbmRpbmcg
cHJvcGVydGllcyI/DQoNCj5UaGUgcmVjZWl2ZXIgc2hvdWxkIGJlIGFibGUgdG8gaGFuZGxlIHN1
Y2ggc2V0dGluZ3MgKGFzIGRlc2NyaWJlZCBieSB0aGVzZSBwYXJhbWV0ZXJzKS4NCj5JIHdpbGwg
YWRqdXN0IHRoYXQgcGFydCB0byByZWZsZWN0IHdoYXQgeW91IHByb3Bvc2UuDQo+DQo+MikgSSB3
aWxsIGluZGVlZCByZXBsYWNlIGNyZWF0b3IvcmVjZWl2ZXIgYnkgb2ZmZXJvci9hbnN3ZXJlciBy
ZXNwZWN0aXZlbHkuIEFzIGZvciB0aGUgYW5zd2VyZXI6IG9uIGFjY2VwdGluZyB0aGUgY29ubmVj
dGlvbiB3aXRoIHRoZSBvZmZlcmVkIHBhcmFtZXRlcnMsIHRoZXJlIGlzIG5vdCBtdWNoIHRvIHNl
bmQgYmFjayB3LnIudC4gcGFyYW1ldGVycy4gDQo+QnV0IGZvciBlYXN5IG9mIHJlY29nbml6aW5n
IHRoZSBuZWdvdGlhdGVkIHN0cmVhbSwgd2UgYmVsaWV2ZSB0aGUgYW5zd2VyZXIgc2hvdWxkIHVz
ZSB0aGUgc2FtZSBmbXRwIChhcyBnaXZlbiBpbiB0aGUgb2ZmZXIpIGluIGl0cyBhbnN3ZXIuDQoN
CkRvZXMgdGhhdCBhbHNvIGluY2x1ZGUgdGhlIGFjdHVhbCBwYXlsb2FkIHR5cGUgbnVtYmVyIHZh
bHVlPw0KDQo+U28sIHVwZGF0ZWQgdGV4dCB3b3VsZCBiZWNvbWU6DQoNCkl0IGxvb2tzIG9rLCBi
dXQgSSBzdWdnZXN0IHRvIGNoYW5nZToNCg0KIm9mZmVyb3Igb2YgdGhlIHNlc3Npb24iIC0+ICJv
ZmZlcmVyIg0KDQoiYW5zd2VyaW5nIGFwcGxpY2F0aW9uIiAtPiAiYW5zd2VyZXIiDQoNCi4uLmJl
Y2F1c2UgdGhhdCBpcyB0aGUgdGVybWlub2xvZ3kgd2UgdXNlIHRvIGlkZW50aXR5IHRoZSBlbnRp
dGllcyB3aGVuIHRhbGtpbmcgYWJvdXQgb2ZmZXIgYW5kIGFuc3dlci4NCg0KQWxzbywgSSBndWVz
cyB5b3Ugc2hvdWxkIHNheSAiU0hBTEwgcmVwbHkgd2l0aCB0aGUgZXhhY3Qgc2FtZSBwYXJhbWV0
ZXIgVkFMVUVTIGluIHRoZS4uLiIuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQovLy0t
LSBTTklQUEVUDQo4LjIuICBVc2FnZSB3aXRoIFNEUCBPZmZlci9BbnN3ZXIgTW9kZWwNCg0KICAg
V2hlbiBKUEVHIFhTIGlzIG9mZmVyZWQgb3ZlciBSVFAgdXNpbmcgU0RQIGluIGFuIG9mZmVyL2Fu
c3dlciBtb2RlbA0KICAgW1JGQzMyNjRdIGZvciBuZWdvdGlhdGlvbiBmb3IgdW5pY2FzdCB1c2Fn
ZSwgdGhlIGZvbGxvd2luZw0KICAgbGltaXRhdGlvbnMgYW5kIHJ1bGVzIGFwcGx5Og0KDQogICAg
ICBUaGUgImE9Zm10cCIgYXR0cmlidXRlIFNIQUxMIGJlIHByZXNlbnQgc3BlY2lmeWluZyB0aGUg
cmVxdWlyZWQNCiAgICAgIHBhcmFtZXRlciAidHJhbnNtb2RlIiBhbmQgTUFZIHNwZWNpZnkgYW55
IG9mIHRoZSBvcHRpb25hbA0KICAgICAgcGFyYW1ldGVycywgYXMgZGVzY3JpYmVkIGluIFNlY3Rp
b24gNy4xLg0KDQogICAgICBBbGwgcGFyYW1ldGVycyBpbiB0aGUgImE9Zm10cCIgYXR0cmlidXRl
IGluZGljYXRlIHNlbmRpbmcNCiAgICAgIGNhcGFiaWxpdGllcyAoaS5lLiBwcm9wZXJ0aWVzIG9m
IHRoZSBwYXlsb2FkKS4NCg0KICAgICAgQW4gYW5zd2VyZXIgb2YgdGhlIFNEUCBpcyByZXF1aXJl
ZCB0byBzdXBwb3J0IGFsbCBwYXJhbWV0ZXJzIGFuZA0KICAgICAgdmFsdWVzIG9mIHRoZSBwYXJh
bWV0ZXJzIHByb3ZpZGVkIGJ5IHRoZSBvZmZlcm9yOyBvdGhlcndpc2UsIHRoZQ0KICAgICAgYW5z
d2VyZXIgU0hBTEwgcmVqZWN0IHRoZSBzZXNzaW9uLiAgSXQgZmFsbHMgb24gdGhlIG9mZmVyb3Ig
b2YgdGhlDQogICAgICBzZXNzaW9uIHRvIHVzZSB2YWx1ZXMgdGhhdCBhcmUgZXhwZWN0ZWQgdG8g
YmUgc3VwcG9ydGVkIGJ5IHRoZQ0KICAgICAgYW5zd2VyaW5nIGFwcGxpY2F0aW9uLiAgSWYgdGhl
IGFuc3dlcmVyIGFjY2VwdHMgdGhlIHNlc3Npb24sIGl0DQogICAgICBTSEFMTCByZXBseSB3aXRo
IHRoZSBleGFjdCBzYW1lIHBhcmFtZXRlcnMgaW4gdGhlICJhPWZtdHAiDQogICAgICBhdHRyaWJ1
dGUgYXMgaXQgd2FzIG9mZmVyZWQuDQovLy0tLSBTTklQUEVUDQoNCg0KSWYgeW91IGJlbGlldmUg
dGhpcyBpcyBvaywgSSB3aWxsIHBvc3QgYW4gdXBkYXRlZCBkcmFmdCB0byB0aGUgZGF0YXRyYWNr
ZXIuDQoNCkJlc3QgcmVnYXJkcywNClRpbS4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KRnJvbTogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv
bT4NClNlbnQ6IE1vbmRheSAzMSBNYXkgMjAyMSAxNjoxMA0KVG86IFRpbSBCcnV5bGFudHMgPFRC
UkBpbnRvcGl4LmNvbT47IFRob21hcyBSaWNodGVyIDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zw
b2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fdGhvbWFzLnJpY2h0ZXItNDBpaXMuZnJhdW5ob2Zl
ci5kZSZkPUR3SUdhUSZjPWV1R1pzdGNhVERsbHZpbUVOOGI3alhyd3FPZi12NUFfQ2RwZ25WZmlp
TU0mcj1MVHhVR3VrTENFZkVVZG9fYnEwNDhRJm09UmQ3cEU0V0Vvb0Jwa3NZREpUcmFwM2lyODlr
U1h4ZElOTE5QVll3ai1zMCZzPVZDczZNSGM4MEttc3lKMGEtclNVNFd5eWlIZU1RaTJmNWlGaVF5
Vy1COVkmZT0+OyBhdnRAaWV0Zi5vcmcNCkNjOiBKZWFuLUJhcHRpc3RlIExvcmVudCA8amIubG9y
ZW50QGludG9waXguY29tPg0KU3ViamVjdDogUkU6IFtBVlRDT1JFXSBTRFAgZGlyZWN0b3JhdGUg
cmV2aWV3IG9mIGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtanBlZ3hzLTEzDQoNCkhpIFRpbSwNCg0K
PkJlZm9yZSBJIHVwbG9hZCBhIG5ldyBkcmFmdCB0byBhZGRyZXNzIHRoZSBTRFAsIEkgd291bGQg
bGlrZSB5b3UgdG8gcmV2aXNlIHRoZSBmb2xsb3dpbmcgdGV4dC4NCj4NCj5BcyB5b3Ugc3RhdGVk
LCB3aGVuIGRlc2NyaWJpbmcgdGhlIFNEUCBvZmZlci9hbnN3ZXIgbW9kZWwsIHRoZSBkcmFmdCBu
ZWVkcyB0byBhZGRyZXNzIHRoZSA1IGZvbGxvd2luZyB0b3BpY3M6DQo+WC4xIEdlbmVyaWMgU0RQ
IENvbnNpZGVyYXRpb25zDQo+WC4yLiAgR2VuZXJhdGluZyB0aGUgSW5pdGlhbCBTRFAgT2ZmZXIN
Cj5YLjMuICBHZW5lcmF0aW5nIHRoZSBTRFAgQW5zd2VyDQo+WC40LiAgT2ZmZXJlciBQcm9jZXNz
aW5nIG9mIHRoZSBTRFAgQW5zd2VyIFguNS4gIE1vZGlmeWluZyB0aGUgU2Vzc2lvbg0KPg0KPk91
ciBxdWVzdGlvbjogSXMgdGhpcyBzdWZmaWNpZW50bHkgZGVzY3JpYmVkIGluIFJGQzMyNjQgYW5k
IGlzIGl0IG9rIHRvIHJlZmVyIHRvIHRoYXQgUkZDIHdpdGggc29tZSBleHRyYSBjbGFyaWZpY2F0
aW9ucz8gUkZDMzI2NCBzZWVtcyB0byBiZSB3aGF0IHdlIGludGVuZCAiaWYiIHNkcCBvZmZlci9h
bnN3ZXIgaXMgdXNlZC4gVGhpcyB3b3VsZCByZXN1bHQgaW4gdGhlIGZvbGxvd2luZyB0ZXh0Og0K
Pg0KPi8vLS0tIFNOSVBQRVQNCj44LjIuICBVc2FnZSB3aXRoIFNEUCBPZmZlci9BbnN3ZXIgTW9k
ZWwNCj4NCj4gICBXaGVuIEpQRUcgWFMgaXMgb2ZmZXJlZCBvdmVyIFJUUCB1c2luZyBTRFAgaW4g
YW4gb2ZmZXIvYW5zd2VyIG1vZGVsDQo+ICAgW1JGQzMyNjRdIGZvciBuZWdvdGlhdGlvbiBmb3Ig
dW5pY2FzdCB1c2FnZSwgdGhlIGZvbGxvd2luZw0KPiAgIGxpbWl0YXRpb25zIGFuZCBydWxlcyBh
cHBseToNCj4NCj4gICAgICBUaGUgImE9Zm10cCIgYXR0cmlidXRlIFNIQUxMIGJlIHByZXNlbnQg
c3BlY2lmeWluZyB0aGUgcmVxdWlyZWQNCj4gICAgICBwYXJhbWV0ZXIgInRyYW5zbW9kZSIgYW5k
IE1BWSBzcGVjaWZ5IGFueSBvZiB0aGUNCj4gICAgICBvcHRpb25hbCBwYXJhbWV0ZXJzLCBhcyBk
ZXNjcmliZWQgaW4gU2VjdGlvbiA3LjEuDQo+DQo+ICAgICAgQWxsIHBheWxvYWQgcGFyYW1ldGVy
cyBhcmUgZGVjbGFyYXRpdmUsIG1lYW5pbmcgdGhhdCB0aGV5IGRlc2NyaWJlDQo+ICAgICAgcHJv
cGVydGllcyBvZiB0aGUgcGF5bG9hZC4NCj4NCj4gICAgICBBIHJlY2VpdmVyIG9mIHRoZSBTRFAg
aXMgcmVxdWlyZWQgdG8gc3VwcG9ydCBhbGwgcGFyYW1ldGVycyBhbmQNCj4gICAgICB2YWx1ZXMg
b2YgdGhlIHBhcmFtZXRlcnMgcHJvdmlkZWQ7IG90aGVyd2lzZSwgdGhlIHJlY2VpdmVyIFNIQUxM
DQo+ICAgICAgcmVqZWN0IHRoZSBzZXNzaW9uLiAgSXQgZmFsbHMgb24gdGhlIGNyZWF0b3Igb2Yg
dGhlIHNlc3Npb24gdG8gdXNlDQo+ICAgICAgdmFsdWVzIHRoYXQgYXJlIGV4cGVjdGVkIHRvIGJl
IHN1cHBvcnRlZCBieSB0aGUgcmVjZWl2aW5nDQo+ICAgICAgYXBwbGljYXRpb24uDQo+Ly8tLS0g
U05JUFBFVA0KPg0KPiBGZWVkYmFjayB3b3VsZCBiZSB2ZXJ5IHdlbGNvbWUuDQoNCkEgY291cGxl
IG9mIGNvbW1lbnRzOg0KDQoNClExOg0KDQoiQWxsIHBheWxvYWQgcGFyYW1ldGVycyBhcmUgZGVj
bGFyYXRpdmUsIG1lYW5pbmcgdGhhdCB0aGV5IGRlc2NyaWJlIHByb3BlcnRpZXMgb2YgdGhlIHBh
eWxvYWQuIg0KDQpJIGRvbid0IHRoaW5rIHlvdSBuZWVkIHRvIHNheSB0aGF0Lg0KDQpCYXNlZCBv
biBvdXIgZWFybGllciBkaXNjdXNzaW9ucywgSSB0aGluayB3aGF0IHlvdSBuZWVkIHRvIHBvaW50
IG91dCBpcyB0aGF0IHRoZSBmbXRwIGF0dHJpYnV0ZSBpcyB1c2VkIHRvIGluZGljYXRlIFNFTkRJ
TkcgY2FwYWJpbGl0aWVzLg0KDQotLS0tDQoNClEyOg0KDQoiQSByZWNlaXZlciBvZiB0aGUgU0RQ
IGlzIHJlcXVpcmVkIHRvIHN1cHBvcnQgYWxsIHBhcmFtZXRlcnMgYW5kIHZhbHVlcyBvZiB0aGUg
cGFyYW1ldGVycyBwcm92aWRlZDsgb3RoZXJ3aXNlLCB0aGUgcmVjZWl2ZXIgU0hBTEwgcmVqZWN0
IHRoZSBzZXNzaW9uLiAgSXQgZmFsbHMgb24gdGhlIGNyZWF0b3Igb2YgdGhlIHNlc3Npb24gdG8g
dXNlIHZhbHVlcyB0aGF0IGFyZSBleHBlY3RlZCB0byBiZSBzdXBwb3J0ZWQgYnkgdGhlIHJlY2Vp
dmluZyBhcHBsaWNhdGlvbi4iDQoNCkluc3RlYWQgb2YgInJlY2VpdmVyIiwgSSB3b3VsZCBzYXkg
YW5zd2VyZXIuDQoNCkluc3RlYWQgb2YgImNyZWF0b3IiLCBJIHdvdWxkIHNheSBvZmZlcmVyLg0K
DQpBbHNvLCBhc3N1bWluZyB0aGUgYW5zd2VyZXIvcmVjZWl2ZXIgYWNjZXB0cyB0aGUgb2ZmZXIs
IHRoZXJlIGlzIG5vIHRleHQgb24gd2hhdCBpdCBpbmNsdWRlcyBpbiB0aGUgYW5zd2VyLiBEb2Vz
IHRoZSBhbnN3ZXJlciBhbHNvIGluY2x1ZGUgYW4gZm10cCBhdHRyaWJ1dGU/IElmIHNvLCB3aGF0
IHZhbHVlcyBkb2VzIGl0IGluY2x1ZGU/DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQoN
Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBhdnQgPGF2dC1ib3VuY2VzQGlldGYu
b3JnPiBPbiBCZWhhbGYgT2YgVGltIEJydXlsYW50cw0KU2VudDogRnJpZGF5IDI4IE1heSAyMDIx
IDEyOjIxDQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u
LmNvbT47IFRob21hcyBSaWNodGVyIDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v
djIvdXJsP3U9aHR0cC0zQV9fdGhvbWFzLnJpY2h0ZXItNDBpaXMuZnJhdW5ob2Zlci5kZSZkPUR3
SUdhUSZjPWV1R1pzdGNhVERsbHZpbUVOOGI3alhyd3FPZi12NUFfQ2RwZ25WZmlpTU0mcj1MVHhV
R3VrTENFZkVVZG9fYnEwNDhRJm09UHZJS25veTJJUk1SX1p5alFHRGZYb0ZBdVpaSlZ1MkxFYTM3
Q0hHbGlHMCZzPWdMXzkxaHd3MkN0ZmhTQ2FRcmJKVHViVU8xS2Vjak50RkZfdzlXT1JENWcmZT0+
OyBhdnRAaWV0Zi5vcmcNCkNjOiBKZWFuLUJhcHRpc3RlIExvcmVudCA8amIubG9yZW50QGludG9w
aXguY29tPg0KU3ViamVjdDogUmU6IFtBVlRDT1JFXSBTRFAgZGlyZWN0b3JhdGUgcmV2aWV3IG9m
IGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtanBlZ3hzLTEzDQoNCkhpIENocmlzdGVyLA0KDQpUaGFu
a3MgZm9yIHRoZSBxdWljayByZXNwb25zZSwgd2UgcmVhbGx5IGFwcHJlY2lhdGUgeW91ciB0aW1l
Lg0KDQpTbywgbGV0IG1lIGVsYWJvcmF0ZSBhIGJpdDoNCg0KPj4gRmlyc3QsIHJlZ2FyZGluZyBS
RkMgODQ1MCwgdGhhdCBzcGVjaWZpY2F0aW9uIHdhcyBwcm9iYWJseSBuZXZlciByZXZpZXdlZCBi
eSB0aGUgU0RQIGRpcmVjdG9yYXRlLCBzbyBJIGNhbid0IHJlYWxseSBjb21tZW50IG9uIHRoYXQu
IEJ1dCwgSSBzZWUgdGhhdCB0aGUgUkZDIGUuZy4sIHNheXMgbm90aGluZyBhYm91dCB3aGV0aGVy
IHRoZSBTRFAgaW5kaWNhdGVzIHNlbmRpbmcgb3IgcmVjZWl2aW5nIGNhcGFiaWxpdGllcy4NCg0K
T2ssIEkgdW5kZXJzdGFuZCB0aGF0IFJGQyA4NDUwIG1pZ2h0IG5vdCBiZSBlbnRpcmVseSBjbGVh
ciBvciB3ZWxsIHdyaXR0ZW4gb24gdGhlIFNEUCBwYXJ0Lg0KDQo+PiBTZWNvbmQsIG5vYm9keSBt
YW5kYXRlcyB5b3UgdG8gdXNlIFNEUCwgYW5kIG1vc3QgcGFydCBvZiB0aGUgc3BlYyBpcyBwcm90
b2NvbCBpbmRlcGVuZGVudC4gQnV0LCB0aGUgIlNEUCBPZmZlci9BbnN3ZXIiIHNlY3Rpb24gZGVz
Y3JpYmVzIHRoZSBTRFAgb2ZmZXIvYW5zd2VyIHByb2NlZHVyZXMsICpJRiogeW91IGNob29zZSB0
byB1c2UgdGhhdCBtZWNoYW5pc20gZm9yIG5lZ290aWF0aW5nIHRoZSBzZXNzaW9uLg0KDQpPay4g
VGhhdCBJIHVuZGVyc3RhbmQuIEluIG91ciBjYXNlLCBTRFAgYXMgdGhlIHNlc3Npb24gcHJvdG9j
b2wgaXMgbm90IGNyaXRpY2FsLCBidXQgc3RpbGwgYSBuaWNlIHRvIGhhdmUuIERvIHlvdSBhZ3Jl
ZT8gT3IgZG8geW91IHJlY29tbWVuZCB3ZSByZW1vdmUgdGhlIFNEUCBvZmZlci9hbnN3ZXIgc2Vj
dGlvbj8NCg0KV2hhdCB3ZSBkbyBuZWVkIHRvIHNheSBpcyBob3cgdG8gbWFwIHBhcmFtZXRlcnMg
aW50byBhbiBTRFAtY29tcGxpYW50IGZvcm1hdCBkZXNjcmlwdGlvbiwgZm9yIHRoZSBzYW1lIHJl
YXNvbnMgYXMgUkZDIDg0NTAgYW5kIG1hbnkgb3RoZXIgdmlkZW8gcGF5bG9hZCBSRkMncyAoVlA4
LCBWUDksIEguMjY0L0FWQywgSC4yNjUvSEVWQywgZXRjKS4gVGhpcyBhbGxvd3MgdXNpbmcgbWFu
eSBvdGhlciBzZXNzaW9uIG5lZ290aWF0aW9uIHByb3RvY29scyB0aGF0IHJlbHkgb24gdGhlIFNE
UCBkZXNjcmlwdGlvbi4NCg0KPj4gVGhpcmQgLi4uLg0KDQpJIGJlbGlldmUgd2hhdCBpcyB2ZXJ5
IGltcG9ydGFudCB0byBleHBsYWluIGlzIHRoYXQgYWxsIG9mIG91ciBwYXJhbWV0ZXJzIGFyZSBk
ZWNsYXJhdGl2ZSwgbWVhbmluZyB0aGF0IHRoZXkgZGVzY3JpYmUgZXhhY3QgYml0c3RyZWFtIHBy
b3BlcnRpZXMsIGFuZCBub3QgcmVjZWl2ZXIgY2FwYWJpbGl0aWVzLiBUaGUgU0RQIHBhcmFtZXRl
cnMgY2FuIGJlIHVzZWQgdG8gY29tbXVuaWNhdGUgYmV0d2VlbiBzZW5kZXIvcmVjZWl2ZXIgd2hh
dCB0aGV5IHdpc2ggdG8gZXhjaGFuZ2UgYmVmb3JlIHNlbmRpbmcgYWN0dWFsIHBheWxvYWQsIGJ1
dCBub25lIG9mIHRoZXNlIHBhcmFtZXRlcnMgb3IgdmFsdWVzIGFyZSAiZG93bmdyYWRhYmxlIiBv
ciAiaW5jbHVzaXZlIGNhcGFiaWxpdHkgc2V0cyIuIFhTIGRvZXMgbm90IGhhdmUgc3VjaCBjb25j
ZXB0cywgYXMgaXQgaXMgYSBsb3ctY29tcGxleGl0eSBjb2RlYywgaW50ZW5kZWQgcHJpbWFyaWx5
IHRvIHJlcGxhY2UgdW5jb21wcmVzc2VkIHZpZGVvIHN0cmVhbXMuDQoNClNvbWVob3csIHRoaXMg
cmFpc2VzIHRoZSBmb2xsb3dpbmc6DQoNClguMSBHZW5lcmljIFNEUCBDb25zaWRlcmF0aW9ucw0K
ICBJIGJlbGlldmUgaGVyZSB3ZSBleHBsYWluIHRoYXQgcGFyYW1ldGVycyBhcmUgZGVjbGFyYXRp
dmUgYW5kIHJlcHJlc2VudCBiaXRzdHJlYW0vcGF5bG9hZCB2YWx1ZXMvc2V0dGluZ3MuIFNvIGJv
dGggc2lkZXMgY2FuIHVzZSB0aGVzZSB0byBpbmRpY2F0ZSB3aGF0IHRoZSBwYXlsb2FkIHdpbGwg
bG9vayBsaWtlLg0KDQpYLjIuICBHZW5lcmF0aW5nIHRoZSBJbml0aWFsIFNEUCBPZmZlcg0KICBO
b3QgbXVjaCB0byBzYXkgaGVyZS4gQXMgSSB1bmRlcnN0YW5kIGFuIFNEUCBzZXNzaW9uIGNhbiBi
ZSBpbml0aWF0ZWQgZnJvbSBlaXRoZXIgcmVjZWl2ZXIgb3Igc2VuZGVyIHNpZGVzPyBTbywgdGhl
eSBqdXN0IHNlbmQgYSB2YWxpZCBtZWRpYSBkZXNjcmlwdGlvbiBvZiB0aGUgY29udGVudCB0aGV5
IHdhbnQgdG8gZXhjaGFuZ2UuIElmIGVpdGhlciBzaWRlIGNhbm5vdCBoYW5kbGUgY2VydGFpbiBw
YXlsb2FkIHNldHRpbmdzLCB0aGVuIGl0IHNob3VsZCByZWplY3QgdGhlIG9mZmVyIChvciBhbnN3
ZXIpLiBBbiBvZmZlcmVyIGp1c3Qgc2VuZHMgd2hhdCBpdCB3YW50cyB0byByZWNlaXZlIG9yIHNl
bmQuDQoNClguMy4gIEdlbmVyYXRpbmcgdGhlIFNEUCBBbnN3ZXINCiAgSSBkb24ndCB0aGluayB0
aGVyZSBpcyBhbnl0aGluZyBzcGVjaWFsIHRvIG1lbnRpb24gaGVyZT8gVGhlIGFuc3dlcmVyIHRh
a2VzIHRoZSBkZWNsYXJhdGl2ZSBwYXJhbWV0ZXJzIGFuZCBlaXRoZXIgYWNjZXB0cyBvciByZWpl
Y3RzIHRoZSBzZXNzaW9uLiBJdCBzaG91bGQgTk9UIG1vZGlmeSB0aGUgb2ZmZXIgaW4gYW55IHdh
eS4NCg0KWC40LiAgT2ZmZXJlciBQcm9jZXNzaW5nIG9mIHRoZSBTRFAgQW5zd2VyDQogIEkgZG9u
J3QgdGhpbmsgdGhlcmUgaXMgYW55dGhpbmcgc3BlY2lhbCB0byBtZW50aW9uIGhlcmU/IElmIHRo
ZSBhbnN3ZXIgYWNjZXB0ZWQgdGhlIG9mZmVyLCB0aGVuIHRoZSBzdHJlYW0gY2FuIHN0YXJ0Lg0K
DQpYLjUuICBNb2RpZnlpbmcgdGhlIFNlc3Npb24NCiAgTW9kaWZ5aW5nIHRoZSBzZXNzaW9uIGlz
IHBvc3NpYmxlLCBidXQgdGhpcyBpcyB2ZXJ5IGltcGxlbWVudGF0aW9uIHNwZWNpZmljLiBCYXNp
Y2FsbHksIG1vZGlmeWluZyBhIHNlc3Npb24gaXMgdmVyeSBzaW1pbGFyIHRvIGNyZWF0aW9uIG9m
IGEgbmV3IHNlc3Npb24uIEJvdGggc2lkZXMgc2hvdWxkIGFncmVlIG9uIHRoZSBwYXlsb2FkIHRo
ZXkgd2lsbCBleGNoYW5nZS4NCg0KDQpJJ20gc29ycnkgdG8gZHJhZyB0aGlzIG91dCwgYnV0IEkg
dGhpbmsgdGhhdCBoYXZpbmcgdGhpcyBjb252ZXJzYXRpb24gYnkgZW1haWwgaXMgbW9yZSBlZmZp
Y2llbnQgdGhhbiBwb3N0aW5nIGRyYWZ0cyDwn5iKIEkgYXBwcmVjaWF0ZSB5b3VyIGZlZWRiYWNr
Lg0KDQpUaW0uDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENocmlzdGVy
IEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpTZW50OiBGcmlkYXkg
MjggTWF5IDIwMjEgMTA6MzkNClRvOiBUaW0gQnJ1eWxhbnRzIDxUQlJAaW50b3BpeC5jb20+OyBU
aG9tYXMgUmljaHRlciA8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91
PWh0dHAtM0FfX3Rob21hcy5yaWNodGVyLTQwaWlzLmZyYXVuaG9mZXIuZGUmZD1Ed0lHYVEmYz1l
dUdac3RjYVREbGx2aW1FTjhiN2pYcndxT2YtdjVBX0NkcGduVmZpaU1NJnI9TFR4VUd1a0xDRWZF
VWRvX2JxMDQ4USZtPVZ2c2E3dUZBNXowRFduQlNvTkVudmFfNGlqNXJiY1FHT3dMcF9pLTN6N3cm
cz1hdWVKaW9UbHRZMDVreGZCMjFSRk92U1FzejhsdWxUb3lYUXpiY3RKQ3ZjJmU9PjsgYXZ0QGll
dGYub3JnDQpDYzogSmVhbi1CYXB0aXN0ZSBMb3JlbnQgPGpiLmxvcmVudEBpbnRvcGl4LmNvbT4N
ClN1YmplY3Q6IFJFOiBbQVZUQ09SRV0gU0RQIGRpcmVjdG9yYXRlIHJldmlldyBvZiBkcmFmdC1p
ZXRmLXBheWxvYWQtcnRwLWpwZWd4cy0xMw0KDQpIaSwNCg0KRmlyc3QsIHJlZ2FyZGluZyBSRkMg
ODQ1MCwgdGhhdCBzcGVjaWZpY2F0aW9uIHdhcyBwcm9iYWJseSBuZXZlciByZXZpZXdlZCBieSB0
aGUgU0RQIGRpcmVjdG9yYXRlLCBzbyBJIGNhbid0IHJlYWxseSBjb21tZW50IG9uIHRoYXQuIEJ1
dCwgSSBzZWUgdGhhdCB0aGUgUkZDIGUuZy4sIHNheXMgbm90aGluZyBhYm91dCB3aGV0aGVyIHRo
ZSBTRFAgaW5kaWNhdGVzIHNlbmRpbmcgb3IgcmVjZWl2aW5nIGNhcGFiaWxpdGllcy4NCg0KU2Vj
b25kLCBub2JvZHkgbWFuZGF0ZXMgeW91IHRvIHVzZSBTRFAsIGFuZCBtb3N0IHBhcnQgb2YgdGhl
IHNwZWMgaXMgcHJvdG9jb2wgaW5kZXBlbmRlbnQuIEJ1dCwgdGhlICJTRFAgT2ZmZXIvQW5zd2Vy
IiBzZWN0aW9uIGRlc2NyaWJlcyB0aGUgU0RQIG9mZmVyL2Fuc3dlciBwcm9jZWR1cmVzLCAqSUYq
IHlvdSBjaG9vc2UgdG8gdXNlIHRoYXQgbWVjaGFuaXNtIGZvciBuZWdvdGlhdGluZyB0aGUgc2Vz
c2lvbi4NCg0KVGhpcmQsIEkgZG9uJ3QgdGhpbmsgeW91IG5lZWQgdmVyeSBtdWNoIHRleHQuIFRo
ZSBpbXBvcnRhbnQgdGhpbmcgaXMgdG8gc2F5IHdoYXQgaXMgcGxhY2VkIGluIG9mZmVycyBhbmQg
YW5zd2Vycywgd2hldGhlciB0aGVyZSBhcmUgY29uc3RyYWludHMgd2hlbiBnZW5lcmF0aW5nIHRo
ZSBhbnN3ZXIsIGFuZCB3aGV0aGVyIHRoZXJlIGFyZSBjb25zdHJhaW50cyB3aGVuIGl0IGNvbWVz
IHRvIG1vZGlmeWluZyB0aGUgc2Vzc2lvbi4gQW5kLCB5b3UgZG8gTk9UICBuZWVkIHRvIHNwZWNp
ZnkgSE9XIHRvIG1vZGlmeSBhIHNlc3Npb24sIGJ1dCB3aGV0aGVyIHRoZXJlIGFyZSBwYXlsb2Fk
LXNwZWNpZmljIGNvbnN0cmFpbnRzIHdoZW4gZG9pbmcuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVy
DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBUaW0gQnJ1eWxhbnRzIDxUQlJA
aW50b3BpeC5jb20+DQpTZW50OiBwZXJqYW50YWkgMjguIHRvdWtva3V1dGEgMjAyMSA5LjQ5DQpU
bzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT47IFRo
b21hcyBSaWNodGVyIDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9
aHR0cC0zQV9fdGhvbWFzLnJpY2h0ZXItNDBpaXMuZnJhdW5ob2Zlci5kZSZkPUR3SUZBZyZjPWV1
R1pzdGNhVERsbHZpbUVOOGI3alhyd3FPZi12NUFfQ2RwZ25WZmlpTU0mcj1MVHhVR3VrTENFZkVV
ZG9fYnEwNDhRJm09Z2ZCNFBGLXZWQlctSFZ4Y1N4Q3gwN0xDaFExQ1NlcFlOM0pudXZQWnZoZyZz
PVdnMDhpMzIxM2JDeVAwWWI4SGo1aWhwQldqLWRsclZuS0RkamdnT0picUEmZT0+OyBhdnRAaWV0
Zi5vcmcNCkNjOiBKZWFuLUJhcHRpc3RlIExvcmVudCA8amIubG9yZW50QGludG9waXguY29tPg0K
U3ViamVjdDogUkU6IFtBVlRDT1JFXSBTRFAgZGlyZWN0b3JhdGUgcmV2aWV3IG9mIGRyYWZ0LWll
dGYtcGF5bG9hZC1ydHAtanBlZ3hzLTEzDQoNCkhpIENocmlzdGVyLA0KDQpJJ20gYSBsaXR0bGUg
Yml0IHN0dWNrIGluIGhvdyB0byByZXNvbHZlIGFuZCBhZGRyZXNzIHlvdXIgY29tbWVudHMuIE9u
IG9uZSBoYW5kIEkgdW5kZXJzdGFuZCB0aGF0IHdlIHdhbnQgdGhlIHRleHQgdG8gYmUgY2xlYXIs
IGJ1dCBvbiB0aGUgb3RoZXIgaGFuZCB3ZSBkbyBub3Qgd2FudCB0byByZXBlYXQgU0RQIHNwZWNp
ZmljcyB0b28gbXVjaC4gU0RQIGlzIGp1c3Qgb25lIHdheSB0byBuZWdvdGlhdGUgYSBzZXNzaW9u
LCBhbmQgaW4gdGhlIGNhc2Ugb2YgWFMgaXQgaXMgbm90IHRoZSBtb3N0IGNvbW1vbmx5IHVzZWQg
b25lLiBYUyBpcyBub3QgcmVhbGx5IGludGVuZGVkIGZvciB0aGUgY2xhc3NpY2FsIHZpZGVvLWNh
bGwgY2FzZSwgYnV0IHJhdGhlciB0byBzdHJlYW0gaGlnaC1xdWFsaXR5IHZpZGVvIGNvbnRlbnQg
aW4gYSBwcm9mZXNzaW9uYWwgZW52aXJvbm1lbnQuIEl0IGNhbiBiZSB1c2VkIGZvciB2aWRlbyBj
b25mZXJlbmNpbmcsIGJ1dCBiZXR0ZXIgc3VpdGVkIGNvZGVjcyBleGlzdCBmb3IgdGhhdCB1c2Ut
Y2FzZS4NCg0KSG93ZXZlciwgd2hhdCBpcyBpbXBvcnRhbnQgdG8gbGF5IG91dCBjb3JyZWN0bHkg
aXMgdGhlIG1hcHBpbmcgb2YgdGhlIG1lZGlhIHBhcmFtZXRlcnMgaW50byB0aGUgYT1mbXRwIGZp
ZWxkIG9mIFNEUCwgYmVjYXVzZSB0aGlzIGlzIGFjdHVhbGx5IHVzZWQgYnkgbWFueSBvdGhlciBw
cm90b2NvbHMgKHNvLCBqdXN0IHRoZSBtZWRpYSBkZXNjcmlwdGlvbiBwYXJ0IG9mIFNEUCBpcyB1
c2VkKS4NCg0KT3JpZ2luYWxseSwgd2UgYmFzZWQgb3VyIGRyYWZ0IHRleHQgb24gUkZDIDg0NTAg
KFZDLTIgSFEgUlRQIFBheWxvYWQpLiBJbiB0aGF0IHJlc3BlY3QsIHdoYXQgaXMgd3JpdHRlbiB0
aGVyZSBraW5kIG9mIGZpdHMgZXhhY3RseSB3aGF0IHdlIHdhbnQgd2l0aCBYUy4gR2l2ZW4gdGhh
dCB0aGlzIGlzIGEgcHVibGlzaGVkIFJGQywgd2UgYXJlIHB1enplbGVkIGEgYml0IGFzIHRvIHdo
eSBvdXIgZHJhZnQgd291bGQgbmVlZCB0byBlbGFib3JhdGUgc28gZXh0ZW5zaXZlbHkgb24gU0RQ
LiBGb3Igc3VyZSwgd2UnZCBsaWtlIHRvIGFsbG93IFNEUCBvZmZlci9hbnN3ZXIgbmVnb3RpYXRp
b24gd2l0aCBYUy4gQnV0IHRoaXMgaXMgdmVyeSBzaW1wbGU6IGVhY2ggc2lkZSB0ZWxscyB0aGUg
b3RoZXIgc2lkZSB3aGF0IGl0IHN1cHBvcnRzLCBhbmQgdGhhdCdzIGl0LiBJbiBYUyB0aGUgcGFy
YW1ldGVycyBhcmUgZGVjbGFyYXRpdmUsIG1lYW5pbmcgKGF0IGxlYXN0IHRoYXQncyB3aGF0IHdl
IHdhbnQgdG8gZXhwcmVzcykgdGhhdCBlYWNoIHBhcmFtZXRlciBpcyByZXByZXNlbnRzIGFuIGV4
YWN0IHZhbHVlIGFuZCBpcyBub3QgImluY2x1c2l2ZSIgaW50byBhIHJhbmdlIG9mIGxlc3NlciB2
YWx1ZXMuIEluIG90aGVyIHdvcmRzLCB0aGUgb3RoZXIgc2lkZSBjYW5ub3QgZXhwZWN0IHRoYXQg
YSAibGVzc2VyIiB2YWx1ZSBvZiBhIHBhcmFtZXRlciBjYW4gd29yay4NCg0KWW91ciBwcm9wb3Nl
ZCBzdHJ1Y3R1cmUgaXMganVzdCB0byBlbGFib3JhdGUgYW5kIG91dCBvZiBzY29wZS4gQXMgc3Vj
aCwgSSB3b3VsZCBhc2sgeW91IHRvIGNvbnNpZGVyIHRoZSBleGFtcGxlIG9mIFJGQyA4NDUwICh3
aGVyZSB0aGUgdXNlLWNhc2UgYW5kIHB1cnBvc2UgbWF0Y2hlcyB0aGF0IG9mIG91ciBkcmFmdCku
IEZvciBleGFtcGxlOiBXaHkgZG8gd2UgbmVlZCB0byBzdGF0ZSBhbnl0aGluZyBzcGVjaWZpYyBv
biAiTW9kaWZ5aW5nIHRoZSBTZXNzaW9uIj8gSXNuJ3QgdGhpcyBsYXllZCBvdXQgYnkgU0RQIG9u
IGhvdyB0byBtb2RpZnkgYSBzZXNzaW9uPyBUaGVyZSdzIG5vdGhpbmcgc3BlY2lmaWMgdG8gYmUg
cHV0IGluIG91ciBkcmFmdCAod2UgZG8gbm90IHdhbnQgdG8gcHJldmVudCwgbm90IHN1Z2dlc3Qg
dGhpcyBmdW5jdGlvbmFsaXR5KS4NCg0KSSBob3BlIHlvdSBjYW4gdW5kZXJzdGFuZCBvdXIgZGlm
ZmljdWx0eSB3aXRoIHlvdXIgcmVtYXJrcyBhbmQgY29tbWVudHMuIE91ciBwcm9wb3NhbCBhcyBz
dWNoIGlzIHRvIGtlZXAgdGhlIHRleHQgYWJvdXQgU0RQIHZlcnkgc2hvcnQgYW5kIHNpbXBsZS4g
VGhlIFJUUCBQYXlsb2FkIGRyYWZ0IGNhbiBiZSB1c2VkIHdpdGggU0RQLCBidXQgaXQncyBjZXJ0
YWlubHkgbm90IHRoZSBvbmx5IHdheS4NCg0KSSB3aWxsIGJlIHByZXBhcmluZyBhbiB1cGRhdGVk
IGRyYWZ0IHdoaWNoIHRyaWVzIHRvIGJlIHZlcnkgbWluaW1hbCBvbiB0aGUgU0RQIHNwZWNpZmlj
cy4gVW5sZXNzIGFueXRoaW5nIGlzIHRlY2huaWNhbGx5IHdyb25nLCBJIHJlYWxseSBob3BlIHlv
dSBjYW4gYWdyZWUgdG8gaXQgYW5kIG1vdmUgZm9yd2FyZCB3aXRoIHRoZSBwdWJsaWNhdGlvbiBw
cm9jZXNzLg0KDQpCZXN0IHJlZ2FyZHMsDQpUaW0uDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS0NCkZyb206IGF2dCA8YXZ0LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBDaHJp
c3RlciBIb2xtYmVyZw0KU2VudDogV2VkbmVzZGF5IDI2IE1heSAyMDIxIDE4OjQzDQpUbzogVGhv
bWFzIFJpY2h0ZXIgPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o
dHRwLTNBX190aG9tYXMucmljaHRlci00MGlpcy5mcmF1bmhvZmVyLmRlJmQ9RHdJRkFnJmM9ZXVH
WnN0Y2FURGxsdmltRU44YjdqWHJ3cU9mLXY1QV9DZHBnblZmaWlNTSZyPUxUeFVHdWtMQ0VmRVVk
b19icTA0OFEmbT1nZkI0UEYtdlZCVy1IVnhjU3hDeDA3TENoUTFDU2VwWU4zSm51dlBadmhnJnM9
V2cwOGkzMjEzYkN5UDBZYjhIajVpaHBCV2otZGxyVm5LRGRqZ2dPSmJxQSZlPT47IGF2dEBpZXRm
Lm9yZw0KU3ViamVjdDogUmU6IFtBVlRDT1JFXSBTRFAgZGlyZWN0b3JhdGUgcmV2aWV3IG9mIGRy
YWZ0LWlldGYtcGF5bG9hZC1ydHAtanBlZ3hzLTEzDQoNClRoaXMgaXMgYSBzdHJ1Y3R1cmUgdGhh
dCBpcyB0eXBpY2FsbHkgdXNlZCBmb3IgU0RQIG9mZmVyL2Fuc3dlciBwcm9jZWR1cmVzOg0KDQpY
LiAgU0RQIE9mZmVyL0Fuc3dlciBQcm9jZWR1cmVzDQogICAgIFguMS4gIEdlbmVyaWMgU0RQIENv
bnNpZGVyYXRpb25zDQoJPEhlcmUgeW91IGNhbiBkZXNjcmliZSB0aGluZ3Mgd2hpY2ggYXBwbHkg
dG8gYm90aCBvZmZlcnMgYW5kIGFuc3dlcnM+DQogICAgIFguMi4gIEdlbmVyYXRpbmcgdGhlIElu
aXRpYWwgU0RQIE9mZmVyDQoJPEhlcmUgeW91IGRlc2NyaWJlIGhvdyB0aGUgaW5pdGlhbCBTRFAg
b2ZmZXIgZm9yIHRoZSBzZXNzaW9uIGlzIGdlbmVyYXRlZD4NCiAgICAgWC4zLiAgR2VuZXJhdGlu
ZyB0aGUgU0RQIEFuc3dlcg0KCTxIZXJlIHlvdSBkZXNjcmliZSBob3cgdGhlIGFuc3dlcmVyIGdl
bmVyYXRlcyB0aGUgU0RQIGFuc3dlciwgaW5jbHVkaW5nIHdoZXRoZXIgcGFyYW1ldGVycy9wYXJh
bWV0ZXIgdmFsdWVzIG5lZWQgdG8gYmUgYSBzdWJzZXQgb2YgdGhlIHBhcmFtZXRlcnMvcGFyYW1l
dGVyIHZhbHVlcyBpbiB0aGUgb2ZmZXIgZXRjPg0KICAgICBYLjQuICBPZmZlcmVyIFByb2Nlc3Np
bmcgb2YgdGhlIFNEUCBBbnN3ZXINCiAgICAgNy41LiAgTW9kaWZ5aW5nIHRoZSBTZXNzaW9uDQoJ
PEhlcmUgeW91IGRlc2NyaWJlIGNvbnN0cmFpbnRzIHJlbGF0ZWQgdG8gbW9kaWZpY2F0aW9uIG9m
IHRoZSBzZXNzaW9uLCBpbmNsdWRpbmcgd2hldGhlciB0aGVyZSBhcmUgY2VydGFpbiBwYXJhbWV0
ZXJzL3BhcmFtZXRlciB2YWx1ZXMgdGhhdCB5b3UgY2Fubm90IG1vZGlmeSBldGM+DQoNClJlZ2Fy
ZHMsDQoNCkNocmlzdGVyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBhdnQg
PGF2dC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIgSG9sbWJlcmcNClNl
bnQ6IGtlc2tpdmlpa2tvIDI2LiB0b3Vrb2t1dXRhIDIwMjEgMTkuMzgNClRvOiBUaG9tYXMgUmlj
aHRlciA8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0Ff
X3Rob21hcy5yaWNodGVyLTQwaWlzLmZyYXVuaG9mZXIuZGUmZD1Ed0lDQWcmYz1ldUdac3RjYVRE
bGx2aW1FTjhiN2pYcndxT2YtdjVBX0NkcGduVmZpaU1NJnI9TFR4VUd1a0xDRWZFVWRvX2JxMDQ4
USZtPUx0ZWZRaUxoZHJYd1V5Y2FoN1ptc2F5a19kdEhGLWhNRUJ3SG82RHBldDAmcz0tVE8xUWY3
bDFfcWM0a2xSS3ZidVc4X2VENEw4Zjg1T0I1RGFoYjJMUUdFJmU9PjsgYXZ0QGlldGYub3JnDQpT
dWJqZWN0OiBSZTogW0FWVENPUkVdIFNEUCBkaXJlY3RvcmF0ZSByZXZpZXcgb2YgZHJhZnQtaWV0
Zi1wYXlsb2FkLXJ0cC1qcGVneHMtMTMNCg0KSGksDQoNCj4+IFVuZm9ydHVuYXRlbHkgSSBkb24n
dCB0aGluayB3aGF0IHlvdSBleHBsYWluIGFib3ZlIGlzIHZlcnkgY2xlYXIgaW4gDQo+PiB0aGUg
dGV4dC4NCj4+IA0KPj4gQ29uc2lkZXIgdGhlIGZvbGxvd2luZy4NCj4+IA0KPj4gVGhlIG9mZmVy
ZXIgc2VuZHMgYW4gb2ZmZXIuIFRoZSBvZmZlcmVyIHNwZWNpZmllcyB0aGUgY2hhcmFjdGVyaXN0
aWNzIA0KPj4gdGhhdCB0aGUgb2ZmZXJlciB3YW50cyB0byByZWNlaXZlLiBTaW1pbGFybHksIHRo
ZSBhbnN3ZXIgc3BlY2lmaWVzIA0KPj4gdGhlIGNoYXJhY3RlcmlzdGljcyB0aGF0IHRoZSBhbnN3
ZXJlciB3YW50cyB0byByZWNlaXZlIC0gdGhlIGFuc3dlcmVyIA0KPj4gZG9lcyBOT1Qgc3BlY2lm
eSB3aGF0IGl0IGlzIGdvaW5nIHRvIHNlbmQuIHdoaWNoIEkgdGhpbmsgdGhlIHRleHQgaXMgDQo+
PiBjdXJyZW50bHkgZGVzY3JpYmluZy4NCj4NCj4gU29ycnkgdG8gc291bmQgY29uZnVzZWQsIGJ1
dCBtYXliZSB5b3UgY291bGQgZXhwbGFpbiBhIGJpdCBiZXR0ZXIuIFRvIG15IHVuZGVyc3RhbmRp
bmcsIGl0IGlzIHRoZSBvZmZlcmVyIHRoYXQgZGVzY3JpYmVzIHdoYXQgaXQgb2ZmZXJzIHRvIHNl
bmQsIGFuZCBub3QgdGhlIG90aGVyIHdheSBhcm91bmQ/IA0KPiBNYXliZSBJIG1pc3VuZGVyc3Rh
bmQgc29tZXRoaW5nIHZlcnkgZnVuZGFtZW50YWw/IFNvcnJ5IHRvIGFzayB0aGVzZSBlbGVtZW50
YXJ5IHF1ZXN0aW9ucywgYnV0IHRoaXMgaXMgaW1wb3J0YW50IGZvciB0aGUgdGV4dC4NCg0KSW4g
U0RQIE9mZmVyL0Fuc3dlciwgdGhlIGRlZmF1bHQgaXMgdG8gaW5kaWNhdGUgd2hhdCB5b3UgYXJl
IHdpbGxpbmcgdG8gUkVDRUlWRSA6KQ0KDQpUeXBpY2FsbHkgeW91ciByZWNlaXZpbmcgY2FwYWJp
bGl0aWVzIGFsc28gaW1wbGljaXRseSBpbmRpY2F0ZSB3aGF0IHlvdSBhcmUgYWJsZSB0byBzZW5k
LiBGb3IgZXhhbXBsZSwgaWYgSSBhbSBpbmRpY2F0aW5nIHRoYXQgSSBhbSB3aWxsaW5nIHRvIHJl
Y2VpdmUgY29kZWMgWCBpdCBub3JtYWxseSBtZWFucyB0aGF0IEkgYW0gYWxzbyBhYmxlIHRvIHNl
bmQgY29kZWMgWC4NCg0KIEJ1dCwgdGhlcmUgYXJlIGNhc2VzIHdoZXJlIHRoYXQgaXMgbm90IHRy
dWUsIGVzcGVjaWFsbHkgd2hlbiBpdCBjb21lcyB0byB2aWRlbyBjb2RlcyB3aGVyZSB5b3UgdHlw
aWNhbGx5IGhhdmUgbW9yZSBwYXJhbWV0ZXJzIGFzc29jaWF0ZWQgd2l0aCB0aGUgY29kZWMsIGFu
ZCBvbmUgbmVlZHMgdG8gZXhwbGljaXRseSBpbmRpY2F0ZSBzZW5kaW5nIGNhcGFiaWxpdGllcy4g
DQoNCi0tLQ0KDQo+PiAiVGhlIHJlY2VpdmVyIFNIQUxMIGlnbm9yZSBhbnkgdW5yZWNvZ25pemVk
IHBhcmFtZXRlciBvciBpbnZhbGlkIA0KPj4gcGFyYW1ldGVyIHZhbHVlLiINCj4+IA0KPj4gRmly
c3QsIEluIG15IG9waW5pb24gaW52YWxpZCBwYXJhbWV0ZXJzIHZhbHVlcyBzaGFsbCB0cmlnZ2Vy
IGFuIGVycm9yLg0KPj4gDQo+PiBTZWNvbmQsIHdoYXQgaXMgYW4gdW5yZWNvZ25pemVkIHBhcmFt
ZXRlcj8NCj4NCj4gSSB3b25kZXIgd2h5IHdlIG5lZWQgdG8gc3BlY2lmeSB0aGlzLCBpLmUuIHdo
YXQgYSByZWNlaXZlIGRvZXMgYWJvdXQgDQo+IHBhcmFtZXRlcnMgaXQgZG9lcyBub3QgcmVjb2du
aXplPyBFc3NlbnRpYWxseSwgdGhpcyBpcyBhIHByb2JsZW0gb2YgDQo+ICJmb3Jld2FyZCBjb21w
YXRpYmlsaXR5Ii4gV291bGRuJ3QgaXQgYmUgYSBtYXR0ZXIgb2YgaW1wbGVtZW50YXRpb24gd2hl
dGhlciB0aGUgcmVjZWl2ZXIgYWNjZXB0cyBhbiBvZmZlciAobm90ZSB3ZWxsLCB0aGUgcmVjZWl2
ZXIpLCBhbmQgYXR0ZW1wdHMgdG8gZGVjb2RlIGEgc3RyZWFtIG9uIGEgImJlc3QgZWZmb3J0IiBi
YXNpcywga2VlcGluZyBpbiBtaW5kIHRoYXQgdGhlIHN0cmVhbSBpdHNlbGYgaW5jbHVkZXMgYWRk
aXRpb25hbCBtZWFucyB0byBpZGVudGlmeSByZXF1aXJlZCBjYXBhYmlsaXRpZXMgbmVjZXNzYXJ5
IGZvciBhIHN1Y2Nlc3NmdWwgZGVjb2RlLg0KPg0KPiBJZiB0aGF0IGlzIG5vdCBhbiBvcHRpb24s
IHdlIHdvdWxkL2NvdWxkIG5lZWQgbWVhbnMgdG8gaWRlbnRpZnkgdGhlIA0KPiB0eXBlIG9mIHBh
cmFtZXRlcnMgaW4gYSBmb3Jld2FyZCBjb21wYXRpYmxlIHdheS4gSS5lLiwgY29udmVudGlvbnMg
Ynkgd2hpY2ggd2Ugd291bGQgaWRlbnRpZnkgaW4gdGhlIGZ1dHVyZSBwYXJhbWV0ZXJzIGEgcmVj
ZWl2ZXIgY2FuIHNhZmVseSBpZ25vcmUgYW5kIGF0dGVtcHQgdG8gZGVjb2RlLCBhbmQgcGFyYW1l
dGVycyBhIHJlY2VpdmVyIGNhbm5vdCBzYWZlbHkgaWdub3JlLg0KDQpJIHRoaW5rIGl0IGlzIGZp
bmUgdG8gc2F5IHRoYXQgdW5yZWNvZ25pemVkIHBhcmFtZXRlcnMgc2hhbGwgYmUgaWdub3JlZC4g
SXQgaXMgdGhlbiB1cCB0byBmdXR1cmUgc3BlY2lmaWNhdGlvbnMgdG8gd29ycnkgYWJvdXQgYmFj
a3dhcmQgY29tcGF0aWJpbGl0eSwgcmF0aGVyIHRoYW4gdGhpcyBzcGVjaWZpY2F0aW9uIHdvcnJ5
aW5nIGFib3V0IGZvcndhcmQgY29tcGF0aWJpbGl0eS4NCg0KPj4gQWxzbywgdGhlIHRleHQgZG9l
cyBub3Qgc2F5IHdoYXQgcmVzdHJpY3Rpb25zIChpZiBhbnkpIHRoZXJlIGFyZSB3aGVuIA0KPj4g
aXQgY29tZXMgdG8gbW9kaWZ5IHRoZSBzdHJlYW0gZHVyaW5nIGEgc2Vzc2lvbi4gSXMgaXQgYWxs
b3dlZCB0byANCj4+IG1vZGlmeSBhbnkvYWxsIGNoYXJhY3RlcmlzdGljcz8NCj4NCj4gTXkgdW5k
ZXJzdGFuZGluZyBpcyB0aGF0IHlvdSBjYW5ub3QgbW9kaWZ5IGNoYXJhY3RlcmlzdGljcyBkdXJp
bmcgYSANCj4gc2Vzc2lvbi4gSWYgeW91IG5lZWQgdG8gbW9kaWZ5LCB5b3UgbmVlZCB0byBzZXR1
cCBhIG5ldyBzZXNzaW9uIGFuZCANCj4gY2FuY2VsIHRoZSBjdXJyZW50IG9uZS4gRm9yIEpQRUcg
WFMgc3RyZWFtIGRlY29kZXJzLCBvbmUgY2Fubm90IGV4cGVjdCB0aGF0IGFuIGluc3RhbmNpYXRl
ZCBkZWNvZGVyIGNhbiBkZWNvZGUgZnJvbSBtb2RpZmllZCBwYXJhbWV0ZXJzIGluIG1pZC1zdHJl
YW0gbGV2ZWwuIFRoYXQgaXMsIGlmIHlvdSBzdGFydCBkZWNvZGluZyBpbiBmdWxsLUhELCBhbmQg
dGhlbiBzdHJlYW0gcGFyYW1ldGVycyBiZWNvbWUgOEssIHRoZSBkZWNvZGVyIHdpbGwgaGF2ZSB0
byBhYm9ydC4NCg0KVGhlc2Uga2luZCBvZiB0aGluZ3MgbmVlZCB0byBiZSBzcGVjaWZpZWQuIEkg
ZG9uJ3QgdGhpbmsgaXQgbmVlZHMgdG8gYmUgZm9yYmlkZGVuIHRvIHRyeSB0byBtb2RpZnkgc29t
ZXRoaW5nLCBiZWNhdXNlIHRoZXJlIGNvdWxkIGJlIHRleHQgdGhhdCBzdHJvbmdseSByZWNvbW1l
bmRzIGFnYWluc3QgZG9pbmcgaXQuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBdWRpby9WaWRlbyBUcmFu
c3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KYXZ0QGlldGYub3JnDQpodHRwczovL3VybGRlZmVuc2Uu
cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xp
c3RpbmZvX2F2dCZkPUR3SUNBZyZjPWV1R1pzdGNhVERsbHZpbUVOOGI3alhyd3FPZi12NUFfQ2Rw
Z25WZmlpTU0mcj1MVHhVR3VrTENFZkVVZG9fYnEwNDhRJm09THRlZlFpTGhkclh3VXljYWg3Wm1z
YXlrX2R0SEYtaE1FQndIbzZEcGV0MCZzPTF2WlR1RmpJLVFiZXhQNW9YOXBnYTM1ZFpaenRoWEdn
bjdTOFpnb2Q5TEUmZT0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCkF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQphdnRAaWV0
Zi5vcmcNCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z
QV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fYXZ0JmQ9RHdJQ0FnJmM9ZXVHWnN0Y2FU
RGxsdmltRU44YjdqWHJ3cU9mLXY1QV9DZHBnblZmaWlNTSZyPUxUeFVHdWtMQ0VmRVVkb19icTA0
OFEmbT1MdGVmUWlMaGRyWHdVeWNhaDdabXNheWtfZHRIRi1oTUVCd0hvNkRwZXQwJnM9MXZaVHVG
akktUWJleFA1b1g5cGdhMzVkWlp6dGhYR2duN1M4WmdvZDlMRSZlPQ0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBD
b3JlIE1haW50ZW5hbmNlDQphdnRAaWV0Zi5vcmcNCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv
aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9f
YXZ0JmQ9RHdJR2FRJmM9ZXVHWnN0Y2FURGxsdmltRU44YjdqWHJ3cU9mLXY1QV9DZHBnblZmaWlN
TSZyPUxUeFVHdWtMQ0VmRVVkb19icTA0OFEmbT1WdnNhN3VGQTV6MERXbkJTb05FbnZhXzRpajVy
YmNRR093THBfaS0zejd3JnM9b2lMMnBkbDdoXzZMVlktNEU4OGhWVkkxTm9EV3M2akJPTGIxcldy
QV9uSSZlPQ0K



From nobody Mon May 31 09:21:34 2021
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB1D53A1D91 for ; Mon, 31 May 2021 09:21:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level: 
X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Q6mz8xAGrO4 for ; Mon, 31 May 2021 09:21:27 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on060a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::60a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 698713A1D8F for ; Mon, 31 May 2021 09:21:27 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aFBrFMv/jUNatEG6kBZc1jyA304GSDfk0Ysdaz6BYoRBVw124YbJVzn/74HL4ctSLwH2HfIRSPUHpDAJMoi5eD2UayNKDTJydqbAOPYQdPirdcjD/k7S5pfiFrp/2ukBmdodBN/yV78znwKo8egNZTEbC0Ipsp7BUJg5bJCjKDJ8OddlywezfF2GC/zKA6ZOindN4uOKFUvvuiVwt4jXPaHdKCVp+My2sUVaaxS1cXz2GuipBwVr2cHM6wtk8TxyljU1OJ8io+b7xTwQKtO6X/C5VePSy+ny8d/cGUIIKZvwxrhas+AZC97LXswOM76Qr+CALkbtxMikRuGsu1z28g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iISWVagSp9fHItQ5lyqaAnHGVuJJO68F/QDkUDODfcU=; b=F6J0vVoVbE7V1P5sxvcs9B0fR9LvvXyBOSWF3Z1k+r8TQDWGsaAglsOQ1Uda3HLlwJLu5mGAU7F5DTJwZnEuLcWCikBTyzzUcol6UxeDSZzTXVwsBNAbUY8hTAuYavyTIYguwT8KIcFP/cF7sCY9GjoRYAoHvUw45YNmkFuxbOXpd4gtMsBzyAcoudzHefoYDL9/djYui1TdM4yAWVCCaSrB9+Xb6i6RCxey28ePOeAvhbxynueqT/H6p+6R52zXoe0k8gfQnVw0utCXw3AnrIVASDlxGccSOV14U9pZBpQZ+HKvJsaY/0uPYryYiu2wbp4D+RDGeUq8feNHD1nCWA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iISWVagSp9fHItQ5lyqaAnHGVuJJO68F/QDkUDODfcU=; b=nU786pwllRZVK5q8UXlW1SPsKsy/K2vWDm7NN2LPUg38hWyF99bDDFZIo1xMkdEUxsju2Iv35LsfH4VQau0cDL0r2cHZCa2nY1ElyML/7TK5V+bz1SWJ7Z45ae5ba/goUJnCxadoWtEuYD6J2KbSIhNictTlad0xXHCpnKyj3ro=
Received: from AM0PR07MB3860.eurprd07.prod.outlook.com (2603:10a6:208:4c::18) by AM4PR0701MB2195.eurprd07.prod.outlook.com (2603:10a6:200:45::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.12; Mon, 31 May 2021 16:21:23 +0000
Received: from AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::b10f:ebc0:80d:db2]) by AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::b10f:ebc0:80d:db2%7]) with mapi id 15.20.4195.017; Mon, 31 May 2021 16:21:23 +0000
From: Christer Holmberg 
To: Tim Bruylants , Thomas Richter , "avt@ietf.org" 
CC: Jean-Baptiste Lorent 
Thread-Topic: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
Thread-Index: AddLKBOH9HzaEV4jTtmQ8TPYzmKsqwFVwo+gABfRKwAAFpWSgABEymJQAABwR+AAT0NxwAAES3xQAAEQhVAAkqc4oAAOiNkwAACTaHAAASFDQAAC8bWgAABRQOA=
Date: Mon, 31 May 2021 16:21:23 +0000
Message-ID: 
References:    <7aa5e890-47c5-cdb7-5657-26864cec3d4c@iis.fraunhofer.de>          
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: intopix.com; dkim=none (message not signed) header.d=none;intopix.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [80.248.247.159]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 82849b87-9199-4c1b-cb45-08d92450222a
x-ms-traffictypediagnostic: AM4PR0701MB2195:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: jjTk7lRN14Qbvu3zRnUSQTMf3p2hODAt0paYsoH0MjnSV4ZrM0GIjieQPWgalVEEa04AwHJXAczl9X5zHbu2i1/l9EkbsSKs9scnBPfbBkn4Mfgz872QCK1uE60Lciu35wC6B+sJabLwvqJxnoeCo/rV3BfJmqyb3CZ8mCuk73Mov0AEzHypJVNYJqEIRyWENepEl/vN7gSnb7QgGk5fjPudhNmseh19oZRo2Y2OL4BTjgIUXJKSIblP63BChhlady2MbPGtbPwaSTZbwbKHb9g/u2gBYePuzyao3V6mSpgfeeYHjxpUT/pbWtb2vUGTH6CqcnSZ6b4IviQIbAPtpwpotVvjamVpBW4OoKA3M4Y/8h9ihkOIVauAQmS7iblobYUuDq4SYI5TlrtgnXdkLUc3VcMI4I2yv7GOzoni2lIC/oniUNal1D+pO+7NvsOYdJRJTh4WEfarJdVpxx9CHpfpPCeF17vr86Scmwszo0BUJdkyW8q7P0IwOdjEDTZET+2TQPCirZxcjVNIwbcqXFjiCdPZEaV+Eez2np201FAlZdNheTReH0yBDlVEpOOzTCcElA7KOzenpdEhsu9cm0MO0wmzXQppeJWTZwipVyp6jIaz2xixDsDEBVPZm4xTt25rVxSb+Xa9xFhJDs/1xTh6Gyj5CJDawQDMOzPha+4DL1KqYXkFGQfvZswu2pH9H7xcm4DOz0NFkMxGpUgE2JOnBLX4O0GJ+vsFHMxpvVI=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:AM0PR07MB3860.eurprd07.prod.outlook.com; PTR:; CAT:NONE;  SFS:(4636009)(39860400002)(376002)(346002)(136003)(366004)(396003)(55016002)(83380400001)(316002)(52536014)(64756008)(71200400001)(66476007)(8676002)(30864003)(53546011)(66556008)(26005)(76116006)(7696005)(66446008)(9686003)(8936002)(66946007)(2906002)(38100700002)(478600001)(86362001)(44832011)(186003)(6506007)(110136005)(4326008)(33656002)(5660300002)(966005)(122000001)(579004); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?utf-8?B?WE5MK1BHY29hYmE4OXRKb1ZDT3paeXMvVFZqajhlaTdnbEV4L042QzhpRkdh?= =?utf-8?B?QW5DZGQ3Rnh3b21LWHphQVQ5ZkE3VGlZNThMWlo2TnNoMG9qaG5vRnBxd3N2?= =?utf-8?B?ZnhTamJPck5FU1V1aVlJd2tTZ016UGlJMi9wWkl2ZkxwMm1sd1UwSXo3OG80?= =?utf-8?B?R211WmNybzNSMUlFcFQza0RvaFkrd1krQlNwMndSNVlVcGRRZ3BLbWRSbGRt?= =?utf-8?B?RzRMeTFDbi9XQVEzTTFMdEVSdCtsQVVBOVRKYUwrL3FLcWdGTyszRlVhcGZr?= =?utf-8?B?QnNvMmhvN1FaRGFjWXVDNklISnIzWG5WWWozd3pIRDliOHRmUTcrU281azdK?= =?utf-8?B?UTJiNjFmUzlvSVpST2UrQUlYSG1GN1lMQXpUZDRqZFNKU0J1amJPQS95cTE5?= =?utf-8?B?aWExUHgvdFhrMEI4L0lLa3pSdlAvY0hXeFlZZ01OeVJYZkY4d0NVa21wdGor?= =?utf-8?B?Qy8yOGZPdUhNZnkxelhEeTZnWHV3YkhMRWNpbkxMcVhNVVBEQXkxZExnS24x?= =?utf-8?B?TVliQW41R2VsWkxnOTZIOVJ3QnFvVlI0U2JDcktMSnBYNW9Ub01tT0pMN2d1?= =?utf-8?B?azFRYTY3MnMyMzNRVEsvTHVqbFk3K3BqSkVRbGZMaWdHQ3ZGVHZxRUt6SXdB?= =?utf-8?B?WE4yNXdpMXZ0QUVtM1FORVQ2WlNtZ0c0di9VS2JnQ0pYa242RDUwZGdSU3NM?= =?utf-8?B?V2ZUQWd4bXBXYkNUaUdJQWs1dHZUYjZ0d0M1L3ZqTlUvSGNVRkxlcFRPOEd3?= =?utf-8?B?aUVaM1Jic2k2OERnc0hMZzhSVC8vMWtvbFVjVzFuQThhdzgxb2VYSy9Wb2tF?= =?utf-8?B?WVQzQklPTHN4cjV1Z3Nnd29zdy96OThrcG1iM2NsbkQwTkE5MkVDZ0k1L3hz?= =?utf-8?B?d0UzSkRFYjlBcWs0aHBtTXhkZjBOaVRQd1R1MUdPYzFxU0dZRVkwREdDL3hY?= =?utf-8?B?RWxJanFRcVBlMGNEdkI1TURpeDVZcCszSmw4eG1KMUJ0ZEhtZmZSS0FJZk4x?= =?utf-8?B?bWlQdUlHUXF2ejAwYTZmM1UxRENtMDlrVWt4K3dlTlRyU1VyaFdoNEs3NHgx?= =?utf-8?B?c2lqZkF4VEVLS1hGRDN5MzQvOUlScVc5QlBGbDB1WWJtVDVTdmM4V29WVkFx?= =?utf-8?B?bFBBUVQ1bVNldzJVMHlBTzA4U1ZYVml6MTdtWGhmaGJnR25OV3g2U0NaOFF4?= =?utf-8?B?cFUwOTBHZmdTbjRQOWIveU80Kys5Wkh4dkwyazdXYThMSU9hMzBqYlFxd0NU?= =?utf-8?B?T0l4UVVJeHhJNVhoNEowdk5vZU1jamRHalVrSEJKWHVkWWlITnN4N1JNZmZ6?= =?utf-8?B?L2g4N283UGYrcHVudVZVUnEycDQwLzZiTVUyb0lhNEdGNmdLQ1JlbE5LTFla?= =?utf-8?B?YnBqMDJhQkFBdGFaeExBanJaS1BUZlhJWG4yUHYvZFhkczdRdjErcmlLcXZV?= =?utf-8?B?R1FlSjBLN3N1MnRMRG81MzZmQUI0Y25rMVJpeFVrN2JoTVRzbkVYMUVqYkFT?= =?utf-8?B?U0xBY1BlVG85MlE5RjVUYW9VWGhGYnZLRk5PNVEvSlJqcUQ2cVErVG83UU02?= =?utf-8?B?L3pTZEF6dUw1cU1Fb3Q3QjY5dWx2Y0lKQ3V2V3FVY2NUakFVOTY0SFdGaStU?= =?utf-8?B?cmpVV0IyWGxJZ2dSbVVMQzJHUTdWOGNnVkNxclRkTU8vQTlZOEQyb21qa2ZO?= =?utf-8?B?NlBUR1EzUFU3TXNQQ20zWG13OGJkcUg3WDlRYmdTRmJJV2hocGh5Z1hwdDVG?= =?utf-8?Q?9uFumMLUn7oMi6ZLb7RD8DSN8vjuPZi6O5S3a3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB3860.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 82849b87-9199-4c1b-cb45-08d92450222a
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2021 16:21:23.7709 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: VI0W5qzkMrBqOT0Un9vzSjBzlxNWg1x20FYVm9cszXcGd9iDb4DaDoosj23weTdMWH8hOF7B2eAB+JLvJrlu+PFdq3vHJk+zbXuZsCpzdBQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0701MB2195
Archived-At: 
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 May 2021 16:21:33 -0000

SGksDQoNCj4xKSBJIGJlbGlldmUgIi4uLiBzZW5kaW5nIGNhcGFiaWxpdGllcyAoaS5lLiBwcm9w
ZXJ0aWVzIG9mIHRoZSBwYXlsb2FkKS4uLiIgaXMgY29ycmVjdC4NCj4NCj4yYSkgSSdtIG5vdCAx
MDAlIHN1cmUgdGhhdCBJIHVuZGVyc3RhbmQgd2hhdCB5b3UgbWVhbiBieSB0aGlzLiBOb3JtYWxs
eSBJIHdvdWxkIGFzc3VtZSB0aGF0IHRoZSBzYW1lIHBheWxvYWQgdHlwZSBpcyB0byBiZSB1c2Vk
IGluIGFuIGFuc3dlciAodG8gc2ltcGxpZnkgdGhpbmdzKS4gQWxsdGhvdWdoIGluIFJGQzMyNjQg
dGhpcyBpcyBhIFNIT1VMRCBhbmQgbm90IGEgTVVTVC4gU28sIEkgYWRkZWQgYSBzZW50ZW5jZSB0
byBhbHNvIHJlY29tbWVuZCB0aGlzLg0KDQpTb3JyeSBmb3IgYmVpbmcgdW5jbGVhci4gSSBtZWFu
dCB0aGUgbnVtZXJpYyBudW1iZXIgdmFsdWUgdGhhdCBpcyBhc3NpZ25lZCB0byB0aGUgcGF5bG9h
ZC4gSSBzZWUgdGhhdCB5b3UgaGF2ZSBjb3ZlcmVkIHRoYXQgbm93IDopDQoNCj4yYikgSSBtYWRl
IHRoZSBzdWdnZXN0ZWQgY2hhbmdlcyAob2ZmZXJlci9hbnN3ZXJlcikuIEl0IGlzIGdvb2QgdG8g
Zm9sbG93IGNvbW1vbiB0ZXJtaW5vbG9neS4gSSBhbHNvIGFncmVlIGFib3V0IHRoZSBWQUxVRVMg
KEkgd2FzIGluIGRvdWJ0IHdoZW4gd3JpdGluZyB0aGF0IHNlbnRlbmNlIGFib3V0IHRoaXMsIHNv
IGl0J3MgZ29vZCB0aGF0IHlvdSBtZW50aW9uIHRoaXMpLg0KDQpUaGUgdGV4dCBsb29rcyBvayBu
b3cuDQoNClRoYW5rcyENCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQovLy0tLSBTTklQUEVU
DQo4LjIuICBVc2FnZSB3aXRoIFNEUCBPZmZlci9BbnN3ZXIgTW9kZWwNCg0KICAgV2hlbiBKUEVH
IFhTIGlzIG9mZmVyZWQgb3ZlciBSVFAgdXNpbmcgU0RQIGluIGFuIG9mZmVyL2Fuc3dlciBtb2Rl
bA0KICAgW1JGQzMyNjRdIGZvciBuZWdvdGlhdGlvbiBmb3IgdW5pY2FzdCB1c2FnZSwgdGhlIGZv
bGxvd2luZw0KICAgbGltaXRhdGlvbnMgYW5kIHJ1bGVzIGFwcGx5Og0KDQogICAgICBUaGUgImE9
Zm10cCIgYXR0cmlidXRlIFNIQUxMIGJlIHByZXNlbnQgc3BlY2lmeWluZyB0aGUgcmVxdWlyZWQN
CiAgICAgIHBhcmFtZXRlciAidHJhbnNtb2RlIiBhbmQgTUFZIHNwZWNpZnkgYW55IG9mIHRoZSBv
cHRpb25hbA0KICAgICAgcGFyYW1ldGVycywgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNy4xLg0K
DQogICAgICBBbGwgcGFyYW1ldGVycyBpbiB0aGUgImE9Zm10cCIgYXR0cmlidXRlIGluZGljYXRl
IHNlbmRpbmcNCiAgICAgIGNhcGFiaWxpdGllcyAoaS5lLiBwcm9wZXJ0aWVzIG9mIHRoZSBwYXls
b2FkKS4NCg0KICAgICAgQW4gYW5zd2VyZXIgb2YgdGhlIFNEUCBpcyByZXF1aXJlZCB0byBzdXBw
b3J0IGFsbCBwYXJhbWV0ZXJzIGFuZA0KICAgICAgdmFsdWVzIG9mIHRoZSBwYXJhbWV0ZXJzIHBy
b3ZpZGVkIGJ5IHRoZSBvZmZlcmVyOyBvdGhlcndpc2UsIHRoZQ0KICAgICAgYW5zd2VyZXIgU0hB
TEwgcmVqZWN0IHRoZSBzZXNzaW9uLiAgSXQgZmFsbHMgb24gdGhlIG9mZmVyZXIgdG8gdXNlDQog
ICAgICB2YWx1ZXMgdGhhdCBhcmUgZXhwZWN0ZWQgdG8gYmUgc3VwcG9ydGVkIGJ5IHRoZSBhbnN3
ZXJlci4gIElmIHRoZQ0KICAgICAgYW5zd2VyZXIgYWNjZXB0cyB0aGUgc2Vzc2lvbiwgaXQgU0hB
TEwgcmVwbHkgd2l0aCB0aGUgZXhhY3Qgc2FtZQ0KICAgICAgcGFyYW1ldGVycyB2YWx1ZXMgaW4g
dGhlICJhPWZtdHAiIGF0dHJpYnV0ZSBhcyBpdCB3YXMgb2ZmZXJlZC4NCg0KICAgICAgVGhlIHNh
bWUgUlRQIHBheWxvYWQgdHlwZSBudW1iZXIgdXNlZCBpbiB0aGUgb2ZmZXIgU0hPVUxEIGJlDQog
ICAgICB1c2VkIGluIHRoZSBhbnN3ZXIsIGFzIHNwZWNpZmllZCBpbiBbUkZDMzI2NF0uDQovLy0t
LSBTTklQUEVUDQoNCg0KQmVzdCByZWdhcmRzLA0KVGltLg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCkZyb206IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Bl
cmljc3Nvbi5jb20+DQpTZW50OiBNb25kYXkgMzEgTWF5IDIwMjEgMTY6NTMNClRvOiBUaW0gQnJ1
eWxhbnRzIDxUQlJAaW50b3BpeC5jb20+OyBUaG9tYXMgUmljaHRlciA8dGhvbWFzLnJpY2h0ZXJA
aWlzLmZyYXVuaG9mZXIuZGU+OyBhdnRAaWV0Zi5vcmcNCkNjOiBKZWFuLUJhcHRpc3RlIExvcmVu
dCA8amIubG9yZW50QGludG9waXguY29tPg0KU3ViamVjdDogUkU6IFtBVlRDT1JFXSBTRFAgZGly
ZWN0b3JhdGUgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtanBlZ3hzLTEzDQoNCkhp
IFRpbSwNCg0KPjEpIFlvdSBhcmUgY29ycmVjdCB0aGF0IHRoZSBwYXJhbWV0ZXJzIGFyZSBkZXNj
cmliaW5nIHdoYXQgdGhlIHNlbmRlciB3aWxsIGJlIHVzaW5nIGluIHRoZSBwYXlsb2FkIChzdHJp
Y3RseSBzcGVha2luZyB0aGVzZSBhcmUgbm90IGNhcGFiaWxpdGllcywgYnV0IHJhdGhlciBzdHJp
Y3QgcGF5bG9hZCBzZXR0aW5ncyB0aGF0IHdpbGwgYmUgaG9ub3JlZCkuIA0KDQpGYWlyIGVub3Vn
aC4gUGVyaGFwcyAic2VuZGluZyBwcm9wZXJ0aWVzIj8NCg0KPlRoZSByZWNlaXZlciBzaG91bGQg
YmUgYWJsZSB0byBoYW5kbGUgc3VjaCBzZXR0aW5ncyAoYXMgZGVzY3JpYmVkIGJ5IHRoZXNlIHBh
cmFtZXRlcnMpLg0KPkkgd2lsbCBhZGp1c3QgdGhhdCBwYXJ0IHRvIHJlZmxlY3Qgd2hhdCB5b3Ug
cHJvcG9zZS4NCj4NCj4yKSBJIHdpbGwgaW5kZWVkIHJlcGxhY2UgY3JlYXRvci9yZWNlaXZlciBi
eSBvZmZlcm9yL2Fuc3dlcmVyIHJlc3BlY3RpdmVseS4gQXMgZm9yIHRoZSBhbnN3ZXJlcjogb24g
YWNjZXB0aW5nIHRoZSBjb25uZWN0aW9uIHdpdGggdGhlIG9mZmVyZWQgcGFyYW1ldGVycywgdGhl
cmUgaXMgbm90IG11Y2ggdG8gc2VuZCBiYWNrIHcuci50LiBwYXJhbWV0ZXJzLiANCj5CdXQgZm9y
IGVhc3kgb2YgcmVjb2duaXppbmcgdGhlIG5lZ290aWF0ZWQgc3RyZWFtLCB3ZSBiZWxpZXZlIHRo
ZSBhbnN3ZXJlciBzaG91bGQgdXNlIHRoZSBzYW1lIGZtdHAgKGFzIGdpdmVuIGluIHRoZSBvZmZl
cikgaW4gaXRzIGFuc3dlci4NCg0KRG9lcyB0aGF0IGFsc28gaW5jbHVkZSB0aGUgYWN0dWFsIHBh
eWxvYWQgdHlwZSBudW1iZXIgdmFsdWU/DQoNCj5TbywgdXBkYXRlZCB0ZXh0IHdvdWxkIGJlY29t
ZToNCg0KSXQgbG9va3Mgb2ssIGJ1dCBJIHN1Z2dlc3QgdG8gY2hhbmdlOg0KDQoib2ZmZXJvciBv
ZiB0aGUgc2Vzc2lvbiIgLT4gIm9mZmVyZXIiDQoNCiJhbnN3ZXJpbmcgYXBwbGljYXRpb24iIC0+
ICJhbnN3ZXJlciINCg0KLi4uYmVjYXVzZSB0aGF0IGlzIHRoZSB0ZXJtaW5vbG9neSB3ZSB1c2Ug
dG8gaWRlbnRpdHkgdGhlIGVudGl0aWVzIHdoZW4gdGFsa2luZyBhYm91dCBvZmZlciBhbmQgYW5z
d2VyLg0KDQpBbHNvLCBJIGd1ZXNzIHlvdSBzaG91bGQgc2F5ICJTSEFMTCByZXBseSB3aXRoIHRo
ZSBleGFjdCBzYW1lIHBhcmFtZXRlciBWQUxVRVMgaW4gdGhlLi4uIi4NCg0KUmVnYXJkcywNCg0K
Q2hyaXN0ZXINCg0KDQoNCi8vLS0tIFNOSVBQRVQNCjguMi4gIFVzYWdlIHdpdGggU0RQIE9mZmVy
L0Fuc3dlciBNb2RlbA0KDQogICBXaGVuIEpQRUcgWFMgaXMgb2ZmZXJlZCBvdmVyIFJUUCB1c2lu
ZyBTRFAgaW4gYW4gb2ZmZXIvYW5zd2VyIG1vZGVsDQogICBbUkZDMzI2NF0gZm9yIG5lZ290aWF0
aW9uIGZvciB1bmljYXN0IHVzYWdlLCB0aGUgZm9sbG93aW5nDQogICBsaW1pdGF0aW9ucyBhbmQg
cnVsZXMgYXBwbHk6DQoNCiAgICAgIFRoZSAiYT1mbXRwIiBhdHRyaWJ1dGUgU0hBTEwgYmUgcHJl
c2VudCBzcGVjaWZ5aW5nIHRoZSByZXF1aXJlZA0KICAgICAgcGFyYW1ldGVyICJ0cmFuc21vZGUi
IGFuZCBNQVkgc3BlY2lmeSBhbnkgb2YgdGhlIG9wdGlvbmFsDQogICAgICBwYXJhbWV0ZXJzLCBh
cyBkZXNjcmliZWQgaW4gU2VjdGlvbiA3LjEuDQoNCiAgICAgIEFsbCBwYXJhbWV0ZXJzIGluIHRo
ZSAiYT1mbXRwIiBhdHRyaWJ1dGUgaW5kaWNhdGUgc2VuZGluZw0KICAgICAgY2FwYWJpbGl0aWVz
IChpLmUuIHByb3BlcnRpZXMgb2YgdGhlIHBheWxvYWQpLg0KDQogICAgICBBbiBhbnN3ZXJlciBv
ZiB0aGUgU0RQIGlzIHJlcXVpcmVkIHRvIHN1cHBvcnQgYWxsIHBhcmFtZXRlcnMgYW5kDQogICAg
ICB2YWx1ZXMgb2YgdGhlIHBhcmFtZXRlcnMgcHJvdmlkZWQgYnkgdGhlIG9mZmVyb3I7IG90aGVy
d2lzZSwgdGhlDQogICAgICBhbnN3ZXJlciBTSEFMTCByZWplY3QgdGhlIHNlc3Npb24uICBJdCBm
YWxscyBvbiB0aGUgb2ZmZXJvciBvZiB0aGUNCiAgICAgIHNlc3Npb24gdG8gdXNlIHZhbHVlcyB0
aGF0IGFyZSBleHBlY3RlZCB0byBiZSBzdXBwb3J0ZWQgYnkgdGhlDQogICAgICBhbnN3ZXJpbmcg
YXBwbGljYXRpb24uICBJZiB0aGUgYW5zd2VyZXIgYWNjZXB0cyB0aGUgc2Vzc2lvbiwgaXQNCiAg
ICAgIFNIQUxMIHJlcGx5IHdpdGggdGhlIGV4YWN0IHNhbWUgcGFyYW1ldGVycyBpbiB0aGUgImE9
Zm10cCINCiAgICAgIGF0dHJpYnV0ZSBhcyBpdCB3YXMgb2ZmZXJlZC4NCi8vLS0tIFNOSVBQRVQN
Cg0KDQpJZiB5b3UgYmVsaWV2ZSB0aGlzIGlzIG9rLCBJIHdpbGwgcG9zdCBhbiB1cGRhdGVkIGRy
YWZ0IHRvIHRoZSBkYXRhdHJhY2tlci4NCg0KQmVzdCByZWdhcmRzLA0KVGltLg0KDQoNCi0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIu
aG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KU2VudDogTW9uZGF5IDMxIE1heSAyMDIxIDE2OjEwDQpU
bzogVGltIEJydXlsYW50cyA8VEJSQGludG9waXguY29tPjsgVGhvbWFzIFJpY2h0ZXIgPGh0dHBz
Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX190aG9tYXMucmlj
aHRlci00MGlpcy5mcmF1bmhvZmVyLmRlJmQ9RHdJR2FRJmM9ZXVHWnN0Y2FURGxsdmltRU44Yjdq
WHJ3cU9mLXY1QV9DZHBnblZmaWlNTSZyPUxUeFVHdWtMQ0VmRVVkb19icTA0OFEmbT1SZDdwRTRX
RW9vQnBrc1lESlRyYXAzaXI4OWtTWHhkSU5MTlBWWXdqLXMwJnM9VkNzNk1IYzgwS21zeUowYS1y
U1U0V3l5aUhlTVFpMmY1aUZpUXlXLUI5WSZlPT47IGF2dEBpZXRmLm9yZw0KQ2M6IEplYW4tQmFw
dGlzdGUgTG9yZW50IDxqYi5sb3JlbnRAaW50b3BpeC5jb20+DQpTdWJqZWN0OiBSRTogW0FWVENP
UkVdIFNEUCBkaXJlY3RvcmF0ZSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1qcGVn
eHMtMTMNCg0KSGkgVGltLA0KDQo+QmVmb3JlIEkgdXBsb2FkIGEgbmV3IGRyYWZ0IHRvIGFkZHJl
c3MgdGhlIFNEUCwgSSB3b3VsZCBsaWtlIHlvdSB0byByZXZpc2UgdGhlIGZvbGxvd2luZyB0ZXh0
Lg0KPg0KPkFzIHlvdSBzdGF0ZWQsIHdoZW4gZGVzY3JpYmluZyB0aGUgU0RQIG9mZmVyL2Fuc3dl
ciBtb2RlbCwgdGhlIGRyYWZ0IG5lZWRzIHRvIGFkZHJlc3MgdGhlIDUgZm9sbG93aW5nIHRvcGlj
czoNCj5YLjEgR2VuZXJpYyBTRFAgQ29uc2lkZXJhdGlvbnMNCj5YLjIuICBHZW5lcmF0aW5nIHRo
ZSBJbml0aWFsIFNEUCBPZmZlcg0KPlguMy4gIEdlbmVyYXRpbmcgdGhlIFNEUCBBbnN3ZXINCj5Y
LjQuICBPZmZlcmVyIFByb2Nlc3Npbmcgb2YgdGhlIFNEUCBBbnN3ZXIgWC41LiAgTW9kaWZ5aW5n
IHRoZSBTZXNzaW9uDQo+DQo+T3VyIHF1ZXN0aW9uOiBJcyB0aGlzIHN1ZmZpY2llbnRseSBkZXNj
cmliZWQgaW4gUkZDMzI2NCBhbmQgaXMgaXQgb2sgdG8gcmVmZXIgdG8gdGhhdCBSRkMgd2l0aCBz
b21lIGV4dHJhIGNsYXJpZmljYXRpb25zPyBSRkMzMjY0IHNlZW1zIHRvIGJlIHdoYXQgd2UgaW50
ZW5kICJpZiIgc2RwIG9mZmVyL2Fuc3dlciBpcyB1c2VkLiBUaGlzIHdvdWxkIHJlc3VsdCBpbiB0
aGUgZm9sbG93aW5nIHRleHQ6DQo+DQo+Ly8tLS0gU05JUFBFVA0KPjguMi4gIFVzYWdlIHdpdGgg
U0RQIE9mZmVyL0Fuc3dlciBNb2RlbA0KPg0KPiAgIFdoZW4gSlBFRyBYUyBpcyBvZmZlcmVkIG92
ZXIgUlRQIHVzaW5nIFNEUCBpbiBhbiBvZmZlci9hbnN3ZXIgbW9kZWwNCj4gICBbUkZDMzI2NF0g
Zm9yIG5lZ290aWF0aW9uIGZvciB1bmljYXN0IHVzYWdlLCB0aGUgZm9sbG93aW5nDQo+ICAgbGlt
aXRhdGlvbnMgYW5kIHJ1bGVzIGFwcGx5Og0KPg0KPiAgICAgIFRoZSAiYT1mbXRwIiBhdHRyaWJ1
dGUgU0hBTEwgYmUgcHJlc2VudCBzcGVjaWZ5aW5nIHRoZSByZXF1aXJlZA0KPiAgICAgIHBhcmFt
ZXRlciAidHJhbnNtb2RlIiBhbmQgTUFZIHNwZWNpZnkgYW55IG9mIHRoZQ0KPiAgICAgIG9wdGlv
bmFsIHBhcmFtZXRlcnMsIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDcuMS4NCj4NCj4gICAgICBB
bGwgcGF5bG9hZCBwYXJhbWV0ZXJzIGFyZSBkZWNsYXJhdGl2ZSwgbWVhbmluZyB0aGF0IHRoZXkg
ZGVzY3JpYmUNCj4gICAgICBwcm9wZXJ0aWVzIG9mIHRoZSBwYXlsb2FkLg0KPg0KPiAgICAgIEEg
cmVjZWl2ZXIgb2YgdGhlIFNEUCBpcyByZXF1aXJlZCB0byBzdXBwb3J0IGFsbCBwYXJhbWV0ZXJz
IGFuZA0KPiAgICAgIHZhbHVlcyBvZiB0aGUgcGFyYW1ldGVycyBwcm92aWRlZDsgb3RoZXJ3aXNl
LCB0aGUgcmVjZWl2ZXIgU0hBTEwNCj4gICAgICByZWplY3QgdGhlIHNlc3Npb24uICBJdCBmYWxs
cyBvbiB0aGUgY3JlYXRvciBvZiB0aGUgc2Vzc2lvbiB0byB1c2UNCj4gICAgICB2YWx1ZXMgdGhh
dCBhcmUgZXhwZWN0ZWQgdG8gYmUgc3VwcG9ydGVkIGJ5IHRoZSByZWNlaXZpbmcNCj4gICAgICBh
cHBsaWNhdGlvbi4NCj4vLy0tLSBTTklQUEVUDQo+DQo+IEZlZWRiYWNrIHdvdWxkIGJlIHZlcnkg
d2VsY29tZS4NCg0KQSBjb3VwbGUgb2YgY29tbWVudHM6DQoNCg0KUTE6DQoNCiJBbGwgcGF5bG9h
ZCBwYXJhbWV0ZXJzIGFyZSBkZWNsYXJhdGl2ZSwgbWVhbmluZyB0aGF0IHRoZXkgZGVzY3JpYmUg
cHJvcGVydGllcyBvZiB0aGUgcGF5bG9hZC4iDQoNCkkgZG9uJ3QgdGhpbmsgeW91IG5lZWQgdG8g
c2F5IHRoYXQuDQoNCkJhc2VkIG9uIG91ciBlYXJsaWVyIGRpc2N1c3Npb25zLCBJIHRoaW5rIHdo
YXQgeW91IG5lZWQgdG8gcG9pbnQgb3V0IGlzIHRoYXQgdGhlIGZtdHAgYXR0cmlidXRlIGlzIHVz
ZWQgdG8gaW5kaWNhdGUgU0VORElORyBjYXBhYmlsaXRpZXMuDQoNCi0tLS0NCg0KUTI6DQoNCiJB
IHJlY2VpdmVyIG9mIHRoZSBTRFAgaXMgcmVxdWlyZWQgdG8gc3VwcG9ydCBhbGwgcGFyYW1ldGVy
cyBhbmQgdmFsdWVzIG9mIHRoZSBwYXJhbWV0ZXJzIHByb3ZpZGVkOyBvdGhlcndpc2UsIHRoZSBy
ZWNlaXZlciBTSEFMTCByZWplY3QgdGhlIHNlc3Npb24uICBJdCBmYWxscyBvbiB0aGUgY3JlYXRv
ciBvZiB0aGUgc2Vzc2lvbiB0byB1c2UgdmFsdWVzIHRoYXQgYXJlIGV4cGVjdGVkIHRvIGJlIHN1
cHBvcnRlZCBieSB0aGUgcmVjZWl2aW5nIGFwcGxpY2F0aW9uLiINCg0KSW5zdGVhZCBvZiAicmVj
ZWl2ZXIiLCBJIHdvdWxkIHNheSBhbnN3ZXJlci4NCg0KSW5zdGVhZCBvZiAiY3JlYXRvciIsIEkg
d291bGQgc2F5IG9mZmVyZXIuDQoNCkFsc28sIGFzc3VtaW5nIHRoZSBhbnN3ZXJlci9yZWNlaXZl
ciBhY2NlcHRzIHRoZSBvZmZlciwgdGhlcmUgaXMgbm8gdGV4dCBvbiB3aGF0IGl0IGluY2x1ZGVz
IGluIHRoZSBhbnN3ZXIuIERvZXMgdGhlIGFuc3dlcmVyIGFsc28gaW5jbHVkZSBhbiBmbXRwIGF0
dHJpYnV0ZT8gSWYgc28sIHdoYXQgdmFsdWVzIGRvZXMgaXQgaW5jbHVkZT8NCg0KUmVnYXJkcywN
Cg0KQ2hyaXN0ZXINCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGF2
dCA8YXZ0LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBUaW0gQnJ1eWxhbnRzDQpTZW50
OiBGcmlkYXkgMjggTWF5IDIwMjEgMTI6MjENClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0
ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPjsgVGhvbWFzIFJpY2h0ZXIgPGh0dHBzOi8vdXJsZGVm
ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX190aG9tYXMucmljaHRlci00MGlp
cy5mcmF1bmhvZmVyLmRlJmQ9RHdJR2FRJmM9ZXVHWnN0Y2FURGxsdmltRU44YjdqWHJ3cU9mLXY1
QV9DZHBnblZmaWlNTSZyPUxUeFVHdWtMQ0VmRVVkb19icTA0OFEmbT1QdklLbm95MklSTVJfWnlq
UUdEZlhvRkF1WlpKVnUyTEVhMzdDSEdsaUcwJnM9Z0xfOTFod3cyQ3RmaFNDYVFyYkpUdWJVTzFL
ZWNqTnRGRl93OVdPUkQ1ZyZlPT47IGF2dEBpZXRmLm9yZw0KQ2M6IEplYW4tQmFwdGlzdGUgTG9y
ZW50IDxqYi5sb3JlbnRAaW50b3BpeC5jb20+DQpTdWJqZWN0OiBSZTogW0FWVENPUkVdIFNEUCBk
aXJlY3RvcmF0ZSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1qcGVneHMtMTMNCg0K
SGkgQ2hyaXN0ZXIsDQoNClRoYW5rcyBmb3IgdGhlIHF1aWNrIHJlc3BvbnNlLCB3ZSByZWFsbHkg
YXBwcmVjaWF0ZSB5b3VyIHRpbWUuDQoNClNvLCBsZXQgbWUgZWxhYm9yYXRlIGEgYml0Og0KDQo+
PiBGaXJzdCwgcmVnYXJkaW5nIFJGQyA4NDUwLCB0aGF0IHNwZWNpZmljYXRpb24gd2FzIHByb2Jh
Ymx5IG5ldmVyIHJldmlld2VkIGJ5IHRoZSBTRFAgZGlyZWN0b3JhdGUsIHNvIEkgY2FuJ3QgcmVh
bGx5IGNvbW1lbnQgb24gdGhhdC4gQnV0LCBJIHNlZSB0aGF0IHRoZSBSRkMgZS5nLiwgc2F5cyBu
b3RoaW5nIGFib3V0IHdoZXRoZXIgdGhlIFNEUCBpbmRpY2F0ZXMgc2VuZGluZyBvciByZWNlaXZp
bmcgY2FwYWJpbGl0aWVzLg0KDQpPaywgSSB1bmRlcnN0YW5kIHRoYXQgUkZDIDg0NTAgbWlnaHQg
bm90IGJlIGVudGlyZWx5IGNsZWFyIG9yIHdlbGwgd3JpdHRlbiBvbiB0aGUgU0RQIHBhcnQuDQoN
Cj4+IFNlY29uZCwgbm9ib2R5IG1hbmRhdGVzIHlvdSB0byB1c2UgU0RQLCBhbmQgbW9zdCBwYXJ0
IG9mIHRoZSBzcGVjIGlzIHByb3RvY29sIGluZGVwZW5kZW50LiBCdXQsIHRoZSAiU0RQIE9mZmVy
L0Fuc3dlciIgc2VjdGlvbiBkZXNjcmliZXMgdGhlIFNEUCBvZmZlci9hbnN3ZXIgcHJvY2VkdXJl
cywgKklGKiB5b3UgY2hvb3NlIHRvIHVzZSB0aGF0IG1lY2hhbmlzbSBmb3IgbmVnb3RpYXRpbmcg
dGhlIHNlc3Npb24uDQoNCk9rLiBUaGF0IEkgdW5kZXJzdGFuZC4gSW4gb3VyIGNhc2UsIFNEUCBh
cyB0aGUgc2Vzc2lvbiBwcm90b2NvbCBpcyBub3QgY3JpdGljYWwsIGJ1dCBzdGlsbCBhIG5pY2Ug
dG8gaGF2ZS4gRG8geW91IGFncmVlPyBPciBkbyB5b3UgcmVjb21tZW5kIHdlIHJlbW92ZSB0aGUg
U0RQIG9mZmVyL2Fuc3dlciBzZWN0aW9uPw0KDQpXaGF0IHdlIGRvIG5lZWQgdG8gc2F5IGlzIGhv
dyB0byBtYXAgcGFyYW1ldGVycyBpbnRvIGFuIFNEUC1jb21wbGlhbnQgZm9ybWF0IGRlc2NyaXB0
aW9uLCBmb3IgdGhlIHNhbWUgcmVhc29ucyBhcyBSRkMgODQ1MCBhbmQgbWFueSBvdGhlciB2aWRl
byBwYXlsb2FkIFJGQydzIChWUDgsIFZQOSwgSC4yNjQvQVZDLCBILjI2NS9IRVZDLCBldGMpLiBU
aGlzIGFsbG93cyB1c2luZyBtYW55IG90aGVyIHNlc3Npb24gbmVnb3RpYXRpb24gcHJvdG9jb2xz
IHRoYXQgcmVseSBvbiB0aGUgU0RQIGRlc2NyaXB0aW9uLg0KDQo+PiBUaGlyZCAuLi4uDQoNCkkg
YmVsaWV2ZSB3aGF0IGlzIHZlcnkgaW1wb3J0YW50IHRvIGV4cGxhaW4gaXMgdGhhdCBhbGwgb2Yg
b3VyIHBhcmFtZXRlcnMgYXJlIGRlY2xhcmF0aXZlLCBtZWFuaW5nIHRoYXQgdGhleSBkZXNjcmli
ZSBleGFjdCBiaXRzdHJlYW0gcHJvcGVydGllcywgYW5kIG5vdCByZWNlaXZlciBjYXBhYmlsaXRp
ZXMuIFRoZSBTRFAgcGFyYW1ldGVycyBjYW4gYmUgdXNlZCB0byBjb21tdW5pY2F0ZSBiZXR3ZWVu
IHNlbmRlci9yZWNlaXZlciB3aGF0IHRoZXkgd2lzaCB0byBleGNoYW5nZSBiZWZvcmUgc2VuZGlu
ZyBhY3R1YWwgcGF5bG9hZCwgYnV0IG5vbmUgb2YgdGhlc2UgcGFyYW1ldGVycyBvciB2YWx1ZXMg
YXJlICJkb3duZ3JhZGFibGUiIG9yICJpbmNsdXNpdmUgY2FwYWJpbGl0eSBzZXRzIi4gWFMgZG9l
cyBub3QgaGF2ZSBzdWNoIGNvbmNlcHRzLCBhcyBpdCBpcyBhIGxvdy1jb21wbGV4aXR5IGNvZGVj
LCBpbnRlbmRlZCBwcmltYXJpbHkgdG8gcmVwbGFjZSB1bmNvbXByZXNzZWQgdmlkZW8gc3RyZWFt
cy4NCg0KU29tZWhvdywgdGhpcyByYWlzZXMgdGhlIGZvbGxvd2luZzoNCg0KWC4xIEdlbmVyaWMg
U0RQIENvbnNpZGVyYXRpb25zDQogIEkgYmVsaWV2ZSBoZXJlIHdlIGV4cGxhaW4gdGhhdCBwYXJh
bWV0ZXJzIGFyZSBkZWNsYXJhdGl2ZSBhbmQgcmVwcmVzZW50IGJpdHN0cmVhbS9wYXlsb2FkIHZh
bHVlcy9zZXR0aW5ncy4gU28gYm90aCBzaWRlcyBjYW4gdXNlIHRoZXNlIHRvIGluZGljYXRlIHdo
YXQgdGhlIHBheWxvYWQgd2lsbCBsb29rIGxpa2UuDQoNClguMi4gIEdlbmVyYXRpbmcgdGhlIElu
aXRpYWwgU0RQIE9mZmVyDQogIE5vdCBtdWNoIHRvIHNheSBoZXJlLiBBcyBJIHVuZGVyc3RhbmQg
YW4gU0RQIHNlc3Npb24gY2FuIGJlIGluaXRpYXRlZCBmcm9tIGVpdGhlciByZWNlaXZlciBvciBz
ZW5kZXIgc2lkZXM/IFNvLCB0aGV5IGp1c3Qgc2VuZCBhIHZhbGlkIG1lZGlhIGRlc2NyaXB0aW9u
IG9mIHRoZSBjb250ZW50IHRoZXkgd2FudCB0byBleGNoYW5nZS4gSWYgZWl0aGVyIHNpZGUgY2Fu
bm90IGhhbmRsZSBjZXJ0YWluIHBheWxvYWQgc2V0dGluZ3MsIHRoZW4gaXQgc2hvdWxkIHJlamVj
dCB0aGUgb2ZmZXIgKG9yIGFuc3dlcikuIEFuIG9mZmVyZXIganVzdCBzZW5kcyB3aGF0IGl0IHdh
bnRzIHRvIHJlY2VpdmUgb3Igc2VuZC4NCg0KWC4zLiAgR2VuZXJhdGluZyB0aGUgU0RQIEFuc3dl
cg0KICBJIGRvbid0IHRoaW5rIHRoZXJlIGlzIGFueXRoaW5nIHNwZWNpYWwgdG8gbWVudGlvbiBo
ZXJlPyBUaGUgYW5zd2VyZXIgdGFrZXMgdGhlIGRlY2xhcmF0aXZlIHBhcmFtZXRlcnMgYW5kIGVp
dGhlciBhY2NlcHRzIG9yIHJlamVjdHMgdGhlIHNlc3Npb24uIEl0IHNob3VsZCBOT1QgbW9kaWZ5
IHRoZSBvZmZlciBpbiBhbnkgd2F5Lg0KDQpYLjQuICBPZmZlcmVyIFByb2Nlc3Npbmcgb2YgdGhl
IFNEUCBBbnN3ZXINCiAgSSBkb24ndCB0aGluayB0aGVyZSBpcyBhbnl0aGluZyBzcGVjaWFsIHRv
IG1lbnRpb24gaGVyZT8gSWYgdGhlIGFuc3dlciBhY2NlcHRlZCB0aGUgb2ZmZXIsIHRoZW4gdGhl
IHN0cmVhbSBjYW4gc3RhcnQuDQoNClguNS4gIE1vZGlmeWluZyB0aGUgU2Vzc2lvbg0KICBNb2Rp
ZnlpbmcgdGhlIHNlc3Npb24gaXMgcG9zc2libGUsIGJ1dCB0aGlzIGlzIHZlcnkgaW1wbGVtZW50
YXRpb24gc3BlY2lmaWMuIEJhc2ljYWxseSwgbW9kaWZ5aW5nIGEgc2Vzc2lvbiBpcyB2ZXJ5IHNp
bWlsYXIgdG8gY3JlYXRpb24gb2YgYSBuZXcgc2Vzc2lvbi4gQm90aCBzaWRlcyBzaG91bGQgYWdy
ZWUgb24gdGhlIHBheWxvYWQgdGhleSB3aWxsIGV4Y2hhbmdlLg0KDQoNCkknbSBzb3JyeSB0byBk
cmFnIHRoaXMgb3V0LCBidXQgSSB0aGluayB0aGF0IGhhdmluZyB0aGlzIGNvbnZlcnNhdGlvbiBi
eSBlbWFpbCBpcyBtb3JlIGVmZmljaWVudCB0aGFuIHBvc3RpbmcgZHJhZnRzIPCfmIogSSBhcHBy
ZWNpYXRlIHlvdXIgZmVlZGJhY2suDQoNClRpbS4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KRnJvbTogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u
LmNvbT4NClNlbnQ6IEZyaWRheSAyOCBNYXkgMjAyMSAxMDozOQ0KVG86IFRpbSBCcnV5bGFudHMg
PFRCUkBpbnRvcGl4LmNvbT47IFRob21hcyBSaWNodGVyIDxodHRwczovL3VybGRlZmVuc2UucHJv
b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fdGhvbWFzLnJpY2h0ZXItNDBpaXMuZnJhdW5o
b2Zlci5kZSZkPUR3SUdhUSZjPWV1R1pzdGNhVERsbHZpbUVOOGI3alhyd3FPZi12NUFfQ2RwZ25W
ZmlpTU0mcj1MVHhVR3VrTENFZkVVZG9fYnEwNDhRJm09VnZzYTd1RkE1ejBEV25CU29ORW52YV80
aWo1cmJjUUdPd0xwX2ktM3o3dyZzPWF1ZUppb1RsdFkwNWt4ZkIyMVJGT3ZTUXN6OGx1bFRveVhR
emJjdEpDdmMmZT0+OyBhdnRAaWV0Zi5vcmcNCkNjOiBKZWFuLUJhcHRpc3RlIExvcmVudCA8amIu
bG9yZW50QGludG9waXguY29tPg0KU3ViamVjdDogUkU6IFtBVlRDT1JFXSBTRFAgZGlyZWN0b3Jh
dGUgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtanBlZ3hzLTEzDQoNCkhpLA0KDQpG
aXJzdCwgcmVnYXJkaW5nIFJGQyA4NDUwLCB0aGF0IHNwZWNpZmljYXRpb24gd2FzIHByb2JhYmx5
IG5ldmVyIHJldmlld2VkIGJ5IHRoZSBTRFAgZGlyZWN0b3JhdGUsIHNvIEkgY2FuJ3QgcmVhbGx5
IGNvbW1lbnQgb24gdGhhdC4gQnV0LCBJIHNlZSB0aGF0IHRoZSBSRkMgZS5nLiwgc2F5cyBub3Ro
aW5nIGFib3V0IHdoZXRoZXIgdGhlIFNEUCBpbmRpY2F0ZXMgc2VuZGluZyBvciByZWNlaXZpbmcg
Y2FwYWJpbGl0aWVzLg0KDQpTZWNvbmQsIG5vYm9keSBtYW5kYXRlcyB5b3UgdG8gdXNlIFNEUCwg
YW5kIG1vc3QgcGFydCBvZiB0aGUgc3BlYyBpcyBwcm90b2NvbCBpbmRlcGVuZGVudC4gQnV0LCB0
aGUgIlNEUCBPZmZlci9BbnN3ZXIiIHNlY3Rpb24gZGVzY3JpYmVzIHRoZSBTRFAgb2ZmZXIvYW5z
d2VyIHByb2NlZHVyZXMsICpJRiogeW91IGNob29zZSB0byB1c2UgdGhhdCBtZWNoYW5pc20gZm9y
IG5lZ290aWF0aW5nIHRoZSBzZXNzaW9uLg0KDQpUaGlyZCwgSSBkb24ndCB0aGluayB5b3UgbmVl
ZCB2ZXJ5IG11Y2ggdGV4dC4gVGhlIGltcG9ydGFudCB0aGluZyBpcyB0byBzYXkgd2hhdCBpcyBw
bGFjZWQgaW4gb2ZmZXJzIGFuZCBhbnN3ZXJzLCB3aGV0aGVyIHRoZXJlIGFyZSBjb25zdHJhaW50
cyB3aGVuIGdlbmVyYXRpbmcgdGhlIGFuc3dlciwgYW5kIHdoZXRoZXIgdGhlcmUgYXJlIGNvbnN0
cmFpbnRzIHdoZW4gaXQgY29tZXMgdG8gbW9kaWZ5aW5nIHRoZSBzZXNzaW9uLiBBbmQsIHlvdSBk
byBOT1QgIG5lZWQgdG8gc3BlY2lmeSBIT1cgdG8gbW9kaWZ5IGEgc2Vzc2lvbiwgYnV0IHdoZXRo
ZXIgdGhlcmUgYXJlIHBheWxvYWQtc3BlY2lmaWMgY29uc3RyYWludHMgd2hlbiBkb2luZy4NCg0K
UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206
IFRpbSBCcnV5bGFudHMgPFRCUkBpbnRvcGl4LmNvbT4NClNlbnQ6IHBlcmphbnRhaSAyOC4gdG91
a29rdXV0YSAyMDIxIDkuNDkNClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJl
cmdAZXJpY3Nzb24uY29tPjsgVGhvbWFzIFJpY2h0ZXIgPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v
ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX190aG9tYXMucmljaHRlci00MGlpcy5mcmF1bmhv
ZmVyLmRlJmQ9RHdJRkFnJmM9ZXVHWnN0Y2FURGxsdmltRU44YjdqWHJ3cU9mLXY1QV9DZHBnblZm
aWlNTSZyPUxUeFVHdWtMQ0VmRVVkb19icTA0OFEmbT1nZkI0UEYtdlZCVy1IVnhjU3hDeDA3TENo
UTFDU2VwWU4zSm51dlBadmhnJnM9V2cwOGkzMjEzYkN5UDBZYjhIajVpaHBCV2otZGxyVm5LRGRq
Z2dPSmJxQSZlPT47IGF2dEBpZXRmLm9yZw0KQ2M6IEplYW4tQmFwdGlzdGUgTG9yZW50IDxqYi5s
b3JlbnRAaW50b3BpeC5jb20+DQpTdWJqZWN0OiBSRTogW0FWVENPUkVdIFNEUCBkaXJlY3RvcmF0
ZSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1qcGVneHMtMTMNCg0KSGkgQ2hyaXN0
ZXIsDQoNCkknbSBhIGxpdHRsZSBiaXQgc3R1Y2sgaW4gaG93IHRvIHJlc29sdmUgYW5kIGFkZHJl
c3MgeW91ciBjb21tZW50cy4gT24gb25lIGhhbmQgSSB1bmRlcnN0YW5kIHRoYXQgd2Ugd2FudCB0
aGUgdGV4dCB0byBiZSBjbGVhciwgYnV0IG9uIHRoZSBvdGhlciBoYW5kIHdlIGRvIG5vdCB3YW50
IHRvIHJlcGVhdCBTRFAgc3BlY2lmaWNzIHRvbyBtdWNoLiBTRFAgaXMganVzdCBvbmUgd2F5IHRv
IG5lZ290aWF0ZSBhIHNlc3Npb24sIGFuZCBpbiB0aGUgY2FzZSBvZiBYUyBpdCBpcyBub3QgdGhl
IG1vc3QgY29tbW9ubHkgdXNlZCBvbmUuIFhTIGlzIG5vdCByZWFsbHkgaW50ZW5kZWQgZm9yIHRo
ZSBjbGFzc2ljYWwgdmlkZW8tY2FsbCBjYXNlLCBidXQgcmF0aGVyIHRvIHN0cmVhbSBoaWdoLXF1
YWxpdHkgdmlkZW8gY29udGVudCBpbiBhIHByb2Zlc3Npb25hbCBlbnZpcm9ubWVudC4gSXQgY2Fu
IGJlIHVzZWQgZm9yIHZpZGVvIGNvbmZlcmVuY2luZywgYnV0IGJldHRlciBzdWl0ZWQgY29kZWNz
IGV4aXN0IGZvciB0aGF0IHVzZS1jYXNlLg0KDQpIb3dldmVyLCB3aGF0IGlzIGltcG9ydGFudCB0
byBsYXkgb3V0IGNvcnJlY3RseSBpcyB0aGUgbWFwcGluZyBvZiB0aGUgbWVkaWEgcGFyYW1ldGVy
cyBpbnRvIHRoZSBhPWZtdHAgZmllbGQgb2YgU0RQLCBiZWNhdXNlIHRoaXMgaXMgYWN0dWFsbHkg
dXNlZCBieSBtYW55IG90aGVyIHByb3RvY29scyAoc28sIGp1c3QgdGhlIG1lZGlhIGRlc2NyaXB0
aW9uIHBhcnQgb2YgU0RQIGlzIHVzZWQpLg0KDQpPcmlnaW5hbGx5LCB3ZSBiYXNlZCBvdXIgZHJh
ZnQgdGV4dCBvbiBSRkMgODQ1MCAoVkMtMiBIUSBSVFAgUGF5bG9hZCkuIEluIHRoYXQgcmVzcGVj
dCwgd2hhdCBpcyB3cml0dGVuIHRoZXJlIGtpbmQgb2YgZml0cyBleGFjdGx5IHdoYXQgd2Ugd2Fu
dCB3aXRoIFhTLiBHaXZlbiB0aGF0IHRoaXMgaXMgYSBwdWJsaXNoZWQgUkZDLCB3ZSBhcmUgcHV6
emVsZWQgYSBiaXQgYXMgdG8gd2h5IG91ciBkcmFmdCB3b3VsZCBuZWVkIHRvIGVsYWJvcmF0ZSBz
byBleHRlbnNpdmVseSBvbiBTRFAuIEZvciBzdXJlLCB3ZSdkIGxpa2UgdG8gYWxsb3cgU0RQIG9m
ZmVyL2Fuc3dlciBuZWdvdGlhdGlvbiB3aXRoIFhTLiBCdXQgdGhpcyBpcyB2ZXJ5IHNpbXBsZTog
ZWFjaCBzaWRlIHRlbGxzIHRoZSBvdGhlciBzaWRlIHdoYXQgaXQgc3VwcG9ydHMsIGFuZCB0aGF0
J3MgaXQuIEluIFhTIHRoZSBwYXJhbWV0ZXJzIGFyZSBkZWNsYXJhdGl2ZSwgbWVhbmluZyAoYXQg
bGVhc3QgdGhhdCdzIHdoYXQgd2Ugd2FudCB0byBleHByZXNzKSB0aGF0IGVhY2ggcGFyYW1ldGVy
IGlzIHJlcHJlc2VudHMgYW4gZXhhY3QgdmFsdWUgYW5kIGlzIG5vdCAiaW5jbHVzaXZlIiBpbnRv
IGEgcmFuZ2Ugb2YgbGVzc2VyIHZhbHVlcy4gSW4gb3RoZXIgd29yZHMsIHRoZSBvdGhlciBzaWRl
IGNhbm5vdCBleHBlY3QgdGhhdCBhICJsZXNzZXIiIHZhbHVlIG9mIGEgcGFyYW1ldGVyIGNhbiB3
b3JrLg0KDQpZb3VyIHByb3Bvc2VkIHN0cnVjdHVyZSBpcyBqdXN0IHRvIGVsYWJvcmF0ZSBhbmQg
b3V0IG9mIHNjb3BlLiBBcyBzdWNoLCBJIHdvdWxkIGFzayB5b3UgdG8gY29uc2lkZXIgdGhlIGV4
YW1wbGUgb2YgUkZDIDg0NTAgKHdoZXJlIHRoZSB1c2UtY2FzZSBhbmQgcHVycG9zZSBtYXRjaGVz
IHRoYXQgb2Ygb3VyIGRyYWZ0KS4gRm9yIGV4YW1wbGU6IFdoeSBkbyB3ZSBuZWVkIHRvIHN0YXRl
IGFueXRoaW5nIHNwZWNpZmljIG9uICJNb2RpZnlpbmcgdGhlIFNlc3Npb24iPyBJc24ndCB0aGlz
IGxheWVkIG91dCBieSBTRFAgb24gaG93IHRvIG1vZGlmeSBhIHNlc3Npb24/IFRoZXJlJ3Mgbm90
aGluZyBzcGVjaWZpYyB0byBiZSBwdXQgaW4gb3VyIGRyYWZ0ICh3ZSBkbyBub3Qgd2FudCB0byBw
cmV2ZW50LCBub3Qgc3VnZ2VzdCB0aGlzIGZ1bmN0aW9uYWxpdHkpLg0KDQpJIGhvcGUgeW91IGNh
biB1bmRlcnN0YW5kIG91ciBkaWZmaWN1bHR5IHdpdGggeW91ciByZW1hcmtzIGFuZCBjb21tZW50
cy4gT3VyIHByb3Bvc2FsIGFzIHN1Y2ggaXMgdG8ga2VlcCB0aGUgdGV4dCBhYm91dCBTRFAgdmVy
eSBzaG9ydCBhbmQgc2ltcGxlLiBUaGUgUlRQIFBheWxvYWQgZHJhZnQgY2FuIGJlIHVzZWQgd2l0
aCBTRFAsIGJ1dCBpdCdzIGNlcnRhaW5seSBub3QgdGhlIG9ubHkgd2F5Lg0KDQpJIHdpbGwgYmUg
cHJlcGFyaW5nIGFuIHVwZGF0ZWQgZHJhZnQgd2hpY2ggdHJpZXMgdG8gYmUgdmVyeSBtaW5pbWFs
IG9uIHRoZSBTRFAgc3BlY2lmaWNzLiBVbmxlc3MgYW55dGhpbmcgaXMgdGVjaG5pY2FsbHkgd3Jv
bmcsIEkgcmVhbGx5IGhvcGUgeW91IGNhbiBhZ3JlZSB0byBpdCBhbmQgbW92ZSBmb3J3YXJkIHdp
dGggdGhlIHB1YmxpY2F0aW9uIHByb2Nlc3MuDQoNCkJlc3QgcmVnYXJkcywNClRpbS4NCg0KDQot
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogYXZ0IDxhdnQtYm91bmNlc0BpZXRmLm9y
Zz4gT24gQmVoYWxmIE9mIENocmlzdGVyIEhvbG1iZXJnDQpTZW50OiBXZWRuZXNkYXkgMjYgTWF5
IDIwMjEgMTg6NDMNClRvOiBUaG9tYXMgUmljaHRlciA8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29m
cG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3Rob21hcy5yaWNodGVyLTQwaWlzLmZyYXVuaG9m
ZXIuZGUmZD1Ed0lGQWcmYz1ldUdac3RjYVREbGx2aW1FTjhiN2pYcndxT2YtdjVBX0NkcGduVmZp
aU1NJnI9TFR4VUd1a0xDRWZFVWRvX2JxMDQ4USZtPWdmQjRQRi12VkJXLUhWeGNTeEN4MDdMQ2hR
MUNTZXBZTjNKbnV2UFp2aGcmcz1XZzA4aTMyMTNiQ3lQMFliOEhqNWlocEJXai1kbHJWbktEZGpn
Z09KYnFBJmU9PjsgYXZ0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0FWVENPUkVdIFNEUCBkaXJl
Y3RvcmF0ZSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1qcGVneHMtMTMNCg0KVGhp
cyBpcyBhIHN0cnVjdHVyZSB0aGF0IGlzIHR5cGljYWxseSB1c2VkIGZvciBTRFAgb2ZmZXIvYW5z
d2VyIHByb2NlZHVyZXM6DQoNClguICBTRFAgT2ZmZXIvQW5zd2VyIFByb2NlZHVyZXMNCiAgICAg
WC4xLiAgR2VuZXJpYyBTRFAgQ29uc2lkZXJhdGlvbnMNCgk8SGVyZSB5b3UgY2FuIGRlc2NyaWJl
IHRoaW5ncyB3aGljaCBhcHBseSB0byBib3RoIG9mZmVycyBhbmQgYW5zd2Vycz4NCiAgICAgWC4y
LiAgR2VuZXJhdGluZyB0aGUgSW5pdGlhbCBTRFAgT2ZmZXINCgk8SGVyZSB5b3UgZGVzY3JpYmUg
aG93IHRoZSBpbml0aWFsIFNEUCBvZmZlciBmb3IgdGhlIHNlc3Npb24gaXMgZ2VuZXJhdGVkPg0K
ICAgICBYLjMuICBHZW5lcmF0aW5nIHRoZSBTRFAgQW5zd2VyDQoJPEhlcmUgeW91IGRlc2NyaWJl
IGhvdyB0aGUgYW5zd2VyZXIgZ2VuZXJhdGVzIHRoZSBTRFAgYW5zd2VyLCBpbmNsdWRpbmcgd2hl
dGhlciBwYXJhbWV0ZXJzL3BhcmFtZXRlciB2YWx1ZXMgbmVlZCB0byBiZSBhIHN1YnNldCBvZiB0
aGUgcGFyYW1ldGVycy9wYXJhbWV0ZXIgdmFsdWVzIGluIHRoZSBvZmZlciBldGM+DQogICAgIFgu
NC4gIE9mZmVyZXIgUHJvY2Vzc2luZyBvZiB0aGUgU0RQIEFuc3dlcg0KICAgICA3LjUuICBNb2Rp
ZnlpbmcgdGhlIFNlc3Npb24NCgk8SGVyZSB5b3UgZGVzY3JpYmUgY29uc3RyYWludHMgcmVsYXRl
ZCB0byBtb2RpZmljYXRpb24gb2YgdGhlIHNlc3Npb24sIGluY2x1ZGluZyB3aGV0aGVyIHRoZXJl
IGFyZSBjZXJ0YWluIHBhcmFtZXRlcnMvcGFyYW1ldGVyIHZhbHVlcyB0aGF0IHlvdSBjYW5ub3Qg
bW9kaWZ5IGV0Yz4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCkZyb206IGF2dCA8YXZ0LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBD
aHJpc3RlciBIb2xtYmVyZw0KU2VudDoga2Vza2l2aWlra28gMjYuIHRvdWtva3V1dGEgMjAyMSAx
OS4zOA0KVG86IFRob21hcyBSaWNodGVyIDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j
b20vdjIvdXJsP3U9aHR0cC0zQV9fdGhvbWFzLnJpY2h0ZXItNDBpaXMuZnJhdW5ob2Zlci5kZSZk
PUR3SUNBZyZjPWV1R1pzdGNhVERsbHZpbUVOOGI3alhyd3FPZi12NUFfQ2RwZ25WZmlpTU0mcj1M
VHhVR3VrTENFZkVVZG9fYnEwNDhRJm09THRlZlFpTGhkclh3VXljYWg3Wm1zYXlrX2R0SEYtaE1F
QndIbzZEcGV0MCZzPS1UTzFRZjdsMV9xYzRrbFJLdmJ1VzhfZUQ0TDhmODVPQjVEYWhiMkxRR0Um
ZT0+OyBhdnRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQVZUQ09SRV0gU0RQIGRpcmVjdG9yYXRl
IHJldmlldyBvZiBkcmFmdC1pZXRmLXBheWxvYWQtcnRwLWpwZWd4cy0xMw0KDQpIaSwNCg0KPj4g
VW5mb3J0dW5hdGVseSBJIGRvbid0IHRoaW5rIHdoYXQgeW91IGV4cGxhaW4gYWJvdmUgaXMgdmVy
eSBjbGVhciBpbiANCj4+IHRoZSB0ZXh0Lg0KPj4gDQo+PiBDb25zaWRlciB0aGUgZm9sbG93aW5n
Lg0KPj4gDQo+PiBUaGUgb2ZmZXJlciBzZW5kcyBhbiBvZmZlci4gVGhlIG9mZmVyZXIgc3BlY2lm
aWVzIHRoZSBjaGFyYWN0ZXJpc3RpY3MgDQo+PiB0aGF0IHRoZSBvZmZlcmVyIHdhbnRzIHRvIHJl
Y2VpdmUuIFNpbWlsYXJseSwgdGhlIGFuc3dlciBzcGVjaWZpZXMgDQo+PiB0aGUgY2hhcmFjdGVy
aXN0aWNzIHRoYXQgdGhlIGFuc3dlcmVyIHdhbnRzIHRvIHJlY2VpdmUgLSB0aGUgYW5zd2VyZXIg
DQo+PiBkb2VzIE5PVCBzcGVjaWZ5IHdoYXQgaXQgaXMgZ29pbmcgdG8gc2VuZC4gd2hpY2ggSSB0
aGluayB0aGUgdGV4dCBpcyANCj4+IGN1cnJlbnRseSBkZXNjcmliaW5nLg0KPg0KPiBTb3JyeSB0
byBzb3VuZCBjb25mdXNlZCwgYnV0IG1heWJlIHlvdSBjb3VsZCBleHBsYWluIGEgYml0IGJldHRl
ci4gVG8gbXkgdW5kZXJzdGFuZGluZywgaXQgaXMgdGhlIG9mZmVyZXIgdGhhdCBkZXNjcmliZXMg
d2hhdCBpdCBvZmZlcnMgdG8gc2VuZCwgYW5kIG5vdCB0aGUgb3RoZXIgd2F5IGFyb3VuZD8gDQo+
IE1heWJlIEkgbWlzdW5kZXJzdGFuZCBzb21ldGhpbmcgdmVyeSBmdW5kYW1lbnRhbD8gU29ycnkg
dG8gYXNrIHRoZXNlIGVsZW1lbnRhcnkgcXVlc3Rpb25zLCBidXQgdGhpcyBpcyBpbXBvcnRhbnQg
Zm9yIHRoZSB0ZXh0Lg0KDQpJbiBTRFAgT2ZmZXIvQW5zd2VyLCB0aGUgZGVmYXVsdCBpcyB0byBp
bmRpY2F0ZSB3aGF0IHlvdSBhcmUgd2lsbGluZyB0byBSRUNFSVZFIDopDQoNClR5cGljYWxseSB5
b3VyIHJlY2VpdmluZyBjYXBhYmlsaXRpZXMgYWxzbyBpbXBsaWNpdGx5IGluZGljYXRlIHdoYXQg
eW91IGFyZSBhYmxlIHRvIHNlbmQuIEZvciBleGFtcGxlLCBpZiBJIGFtIGluZGljYXRpbmcgdGhh
dCBJIGFtIHdpbGxpbmcgdG8gcmVjZWl2ZSBjb2RlYyBYIGl0IG5vcm1hbGx5IG1lYW5zIHRoYXQg
SSBhbSBhbHNvIGFibGUgdG8gc2VuZCBjb2RlYyBYLg0KDQogQnV0LCB0aGVyZSBhcmUgY2FzZXMg
d2hlcmUgdGhhdCBpcyBub3QgdHJ1ZSwgZXNwZWNpYWxseSB3aGVuIGl0IGNvbWVzIHRvIHZpZGVv
IGNvZGVzIHdoZXJlIHlvdSB0eXBpY2FsbHkgaGF2ZSBtb3JlIHBhcmFtZXRlcnMgYXNzb2NpYXRl
ZCB3aXRoIHRoZSBjb2RlYywgYW5kIG9uZSBuZWVkcyB0byBleHBsaWNpdGx5IGluZGljYXRlIHNl
bmRpbmcgY2FwYWJpbGl0aWVzLiANCg0KLS0tDQoNCj4+ICJUaGUgcmVjZWl2ZXIgU0hBTEwgaWdu
b3JlIGFueSB1bnJlY29nbml6ZWQgcGFyYW1ldGVyIG9yIGludmFsaWQgDQo+PiBwYXJhbWV0ZXIg
dmFsdWUuIg0KPj4gDQo+PiBGaXJzdCwgSW4gbXkgb3BpbmlvbiBpbnZhbGlkIHBhcmFtZXRlcnMg
dmFsdWVzIHNoYWxsIHRyaWdnZXIgYW4gZXJyb3IuDQo+PiANCj4+IFNlY29uZCwgd2hhdCBpcyBh
biB1bnJlY29nbml6ZWQgcGFyYW1ldGVyPw0KPg0KPiBJIHdvbmRlciB3aHkgd2UgbmVlZCB0byBz
cGVjaWZ5IHRoaXMsIGkuZS4gd2hhdCBhIHJlY2VpdmUgZG9lcyBhYm91dCANCj4gcGFyYW1ldGVy
cyBpdCBkb2VzIG5vdCByZWNvZ25pemU/IEVzc2VudGlhbGx5LCB0aGlzIGlzIGEgcHJvYmxlbSBv
ZiANCj4gImZvcmV3YXJkIGNvbXBhdGliaWxpdHkiLiBXb3VsZG4ndCBpdCBiZSBhIG1hdHRlciBv
ZiBpbXBsZW1lbnRhdGlvbiB3aGV0aGVyIHRoZSByZWNlaXZlciBhY2NlcHRzIGFuIG9mZmVyIChu
b3RlIHdlbGwsIHRoZSByZWNlaXZlciksIGFuZCBhdHRlbXB0cyB0byBkZWNvZGUgYSBzdHJlYW0g
b24gYSAiYmVzdCBlZmZvcnQiIGJhc2lzLCBrZWVwaW5nIGluIG1pbmQgdGhhdCB0aGUgc3RyZWFt
IGl0c2VsZiBpbmNsdWRlcyBhZGRpdGlvbmFsIG1lYW5zIHRvIGlkZW50aWZ5IHJlcXVpcmVkIGNh
cGFiaWxpdGllcyBuZWNlc3NhcnkgZm9yIGEgc3VjY2Vzc2Z1bCBkZWNvZGUuDQo+DQo+IElmIHRo
YXQgaXMgbm90IGFuIG9wdGlvbiwgd2Ugd291bGQvY291bGQgbmVlZCBtZWFucyB0byBpZGVudGlm
eSB0aGUgDQo+IHR5cGUgb2YgcGFyYW1ldGVycyBpbiBhIGZvcmV3YXJkIGNvbXBhdGlibGUgd2F5
LiBJLmUuLCBjb252ZW50aW9ucyBieSB3aGljaCB3ZSB3b3VsZCBpZGVudGlmeSBpbiB0aGUgZnV0
dXJlIHBhcmFtZXRlcnMgYSByZWNlaXZlciBjYW4gc2FmZWx5IGlnbm9yZSBhbmQgYXR0ZW1wdCB0
byBkZWNvZGUsIGFuZCBwYXJhbWV0ZXJzIGEgcmVjZWl2ZXIgY2Fubm90IHNhZmVseSBpZ25vcmUu
DQoNCkkgdGhpbmsgaXQgaXMgZmluZSB0byBzYXkgdGhhdCB1bnJlY29nbml6ZWQgcGFyYW1ldGVy
cyBzaGFsbCBiZSBpZ25vcmVkLiBJdCBpcyB0aGVuIHVwIHRvIGZ1dHVyZSBzcGVjaWZpY2F0aW9u
cyB0byB3b3JyeSBhYm91dCBiYWNrd2FyZCBjb21wYXRpYmlsaXR5LCByYXRoZXIgdGhhbiB0aGlz
IHNwZWNpZmljYXRpb24gd29ycnlpbmcgYWJvdXQgZm9yd2FyZCBjb21wYXRpYmlsaXR5Lg0KDQo+
PiBBbHNvLCB0aGUgdGV4dCBkb2VzIG5vdCBzYXkgd2hhdCByZXN0cmljdGlvbnMgKGlmIGFueSkg
dGhlcmUgYXJlIHdoZW4gDQo+PiBpdCBjb21lcyB0byBtb2RpZnkgdGhlIHN0cmVhbSBkdXJpbmcg
YSBzZXNzaW9uLiBJcyBpdCBhbGxvd2VkIHRvIA0KPj4gbW9kaWZ5IGFueS9hbGwgY2hhcmFjdGVy
aXN0aWNzPw0KPg0KPiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgeW91IGNhbm5vdCBtb2RpZnkg
Y2hhcmFjdGVyaXN0aWNzIGR1cmluZyBhIA0KPiBzZXNzaW9uLiBJZiB5b3UgbmVlZCB0byBtb2Rp
ZnksIHlvdSBuZWVkIHRvIHNldHVwIGEgbmV3IHNlc3Npb24gYW5kIA0KPiBjYW5jZWwgdGhlIGN1
cnJlbnQgb25lLiBGb3IgSlBFRyBYUyBzdHJlYW0gZGVjb2RlcnMsIG9uZSBjYW5ub3QgZXhwZWN0
IHRoYXQgYW4gaW5zdGFuY2lhdGVkIGRlY29kZXIgY2FuIGRlY29kZSBmcm9tIG1vZGlmaWVkIHBh
cmFtZXRlcnMgaW4gbWlkLXN0cmVhbSBsZXZlbC4gVGhhdCBpcywgaWYgeW91IHN0YXJ0IGRlY29k
aW5nIGluIGZ1bGwtSEQsIGFuZCB0aGVuIHN0cmVhbSBwYXJhbWV0ZXJzIGJlY29tZSA4SywgdGhl
IGRlY29kZXIgd2lsbCBoYXZlIHRvIGFib3J0Lg0KDQpUaGVzZSBraW5kIG9mIHRoaW5ncyBuZWVk
IHRvIGJlIHNwZWNpZmllZC4gSSBkb24ndCB0aGluayBpdCBuZWVkcyB0byBiZSBmb3JiaWRkZW4g
dG8gdHJ5IHRvIG1vZGlmeSBzb21ldGhpbmcsIGJlY2F1c2UgdGhlcmUgY291bGQgYmUgdGV4dCB0
aGF0IHN0cm9uZ2x5IHJlY29tbWVuZHMgYWdhaW5zdCBkb2luZyBpdC4NCg0KUmVnYXJkcywNCg0K
Q2hyaXN0ZXINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCkF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQphdnRAaWV0Zi5vcmcN
Cmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3
LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fYXZ0JmQ9RHdJQ0FnJmM9ZXVHWnN0Y2FURGxsdmlt
RU44YjdqWHJ3cU9mLXY1QV9DZHBnblZmaWlNTSZyPUxUeFVHdWtMQ0VmRVVkb19icTA0OFEmbT1M
dGVmUWlMaGRyWHdVeWNhaDdabXNheWtfZHRIRi1oTUVCd0hvNkRwZXQwJnM9MXZaVHVGakktUWJl
eFA1b1g5cGdhMzVkWlp6dGhYR2duN1M4WmdvZDlMRSZlPQ0KDQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUg
TWFpbnRlbmFuY2UNCmF2dEBpZXRmLm9yZw0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu
Y29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19hdnQm
ZD1Ed0lDQWcmYz1ldUdac3RjYVREbGx2aW1FTjhiN2pYcndxT2YtdjVBX0NkcGduVmZpaU1NJnI9
TFR4VUd1a0xDRWZFVWRvX2JxMDQ4USZtPUx0ZWZRaUxoZHJYd1V5Y2FoN1ptc2F5a19kdEhGLWhN
RUJ3SG82RHBldDAmcz0xdlpUdUZqSS1RYmV4UDVvWDlwZ2EzNWRaWnp0aFhHZ243UzhaZ29kOUxF
JmU9DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQXVk
aW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UNCmF2dEBpZXRmLm9yZw0KaHR0cHM6
Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5v
cmdfbWFpbG1hbl9saXN0aW5mb19hdnQmZD1Ed0lHYVEmYz1ldUdac3RjYVREbGx2aW1FTjhiN2pY
cndxT2YtdjVBX0NkcGduVmZpaU1NJnI9TFR4VUd1a0xDRWZFVWRvX2JxMDQ4USZtPVZ2c2E3dUZB
NXowRFduQlNvTkVudmFfNGlqNXJiY1FHT3dMcF9pLTN6N3cmcz1vaUwycGRsN2hfNkxWWS00RTg4
aFZWSTFOb0RXczZqQk9MYjFyV3JBX25JJmU9DQo=


From nobody Mon May 31 10:05:44 2021
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F033A1EE3 for ; Mon, 31 May 2021 10:05:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=intopix.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56j5Bo09ZqzV for ; Mon, 31 May 2021 10:05:36 -0700 (PDT)
Received: from dispatchb-eu1.ppe-hosted.com (dispatchb-eu1.ppe-hosted.com [185.132.181.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DA6D3A1EE1 for ; Mon, 31 May 2021 10:05:36 -0700 (PDT)
X-Virus-Scanned: Proofpoint Essentials engine
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp2054.outbound.protection.outlook.com [104.47.0.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1-eu1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id AB6FA740064; Mon, 31 May 2021 17:05:32 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DMr3xyWFCr0It1KVzC0AxpLgjBL9TN5u0qF+lt76bC/4NWBXISOI2p2oXKEfuHw0ah2cNEjti9xzwU2VEhVV5S+wJa7For4jFooks4rNWmmTO4cHXmiNI//nYCQvFre+PqfZl4p9mGtMt9RWsmTJrd0v2sKRbBFjTQs9i9nCJR9NttL6JQZeEphwVl+FIepoFpzcS1+v3aYM0acK9mqfB0iWZ+JDjNow74K8Mkyobe8qKDupJowU/8Tk7D/6+v27EI0HkNHQ7lcppBpUMOc63soROm3fWg1ZH9em74xvfyFFZjFgjZQvDZkaWouga1GB+pr3wc3b8GEdu0BuWy1eRQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VQmtjmlOFL0jqTATGVXrDdFCXkngdYzk3ywYBc25/ME=; b=elYMB9/gc6yZGM7aA47HZdQq0F5b7Jz8jC3cK2UE6kxmXXEoY3WdBjQ9Udsu2lLpsBzMsyIASbMVG+v/m+WvEOgpXEY8H7aIuC4AwETngXkHBNhC0cYFMGyzmHO3pzXJCqEaKHO4oELGwphzYATMg8Rg96Wej2HHPHVUQ0+BFzMPjg/JDoNacRnyAsGu4RZ0DtgasFzMpdcvF5K++pLVk17vqV8SVl2TN1gqtaBsaKKTs29ID0b7IcstiLD2CS4Q1W7zY9ImEf67YdS/iFhAg9H21pVXMUzouasvI/UaGQ+Umhiyl1AnjHNXMrh9vhYJuhYGqrXjPlw4DBXTYndzhQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intopix.com; dmarc=pass action=none header.from=intopix.com; dkim=pass header.d=intopix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intopix.onmicrosoft.com; s=selector1-intopix-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VQmtjmlOFL0jqTATGVXrDdFCXkngdYzk3ywYBc25/ME=; b=k2nXa1yLN9PdwkzEnkYR/5cvpDDIS1krwFmmolZPtVeCAkTsAMjn3TzqpvfBtaPY+Q/aNsm/2k4X44Dxpg9mzOFMP2iSB8urZjgsJJyaie0gGyW6rGmQ9ExjWGuK9EaQ3hzipolPpT+1LpCDjMy3rwj8HUfwpAiEUsc0//BEBN4=
Received: from PR3P192MB0748.EURP192.PROD.OUTLOOK.COM (2603:10a6:102:4f::24) by PR3P192MB1087.EURP192.PROD.OUTLOOK.COM (2603:10a6:102:aa::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.21; Mon, 31 May 2021 17:05:31 +0000
Received: from PR3P192MB0748.EURP192.PROD.OUTLOOK.COM ([fe80::8ab:c06a:c2cf:b0ac]) by PR3P192MB0748.EURP192.PROD.OUTLOOK.COM ([fe80::8ab:c06a:c2cf:b0ac%9]) with mapi id 15.20.4173.030; Mon, 31 May 2021 17:05:31 +0000
From: Tim Bruylants 
To: Christer Holmberg , Thomas Richter , "avt@ietf.org" 
CC: Jean-Baptiste Lorent 
Thread-Topic: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
Thread-Index: AddLKBOH9HzaEV4jTtmQ8TPYzmKsqwFVwo+gABfRKwAAFpWSgABEymJQAABwR+AAT0NxwAAES3xQAAEQhVAAkqc4oAAOiNkwAACTaHAAASFDQAAC8bWgAABRQOAAAZNMIA==
Date: Mon, 31 May 2021 17:05:30 +0000
Message-ID: 
References:    <7aa5e890-47c5-cdb7-5657-26864cec3d4c@iis.fraunhofer.de>           
In-Reply-To: 
Accept-Language: en-US, nl-NL
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=intopix.com;
x-originating-ip: [94.227.86.241]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8cd8d0e2-8a3a-4666-6b15-08d924564bff
x-ms-traffictypediagnostic: PR3P192MB1087:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: vyfi9KO/foZqYkwfhZdokuXshoEa8OIFdNTqMKo18SYx00tOXNmAqP5BPI0AvrOS4kfkc+rio1r9KmOy2Z7P1dZAwBT1QFG0hOVbRi/SfrdO8qrerqRTIrp2iCBHfD4jijji1D/ummg76kr+f0hL/kq2CiPbKS25bZtImKdPl23NF+HtkW3Pws84MEOdMXBtsKcrjgJPvZ732TYshc7SlZzw2fx2g+aXbUTBlKV3+4sk7VuAD2qymmwCs7Wnd4YiHgKkpmoNB/4EmY43nFnLs7G9K8A178QP8y8E+53cVkb+npr4JTOxNR6mCTFc6hZRSYFo8GT+DiK24XfdVlaI+LOpYV+a8C6tepbJOv2jYCZJMTZdbiNChO/qYf9Trmm/Q7zbpgmkKQLxEicp35Sk58Xz7Y+d5juGBuGRilGGQoB8FVzPQUqa4QEMMDQzqvoy0j3D+Ae+W14vzV508/BynBwbNRbXAeOW1Fbb9IQTeaYXJm5CuM+lfrB253I/ShOcYm+NhrGdYQXF+8vwzF7lsqx6Yph95bmOTsZcddFHULWeLH7D9iLCAouhEnjPrkXSa38DjvxA+g/d3IMhRc8Bp0w/8wJ/iTIVi0+JKaaLjLurTMNntrRW6fkl89hYBmzgNs0k+glj4iIC/dRM69WILgUgwcK15k8Csj1zWutrCPXOQcK/3xddv58klpPDV1wkj3LPeg8O4ejtksIS3V41gWYjFxrBm+RWNNQ7DaNOrX8=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:PR3P192MB0748.EURP192.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFS:(136003)(396003)(376002)(346002)(39830400003)(366004)(6506007)(53546011)(30864003)(33656002)(966005)(5660300002)(8936002)(7696005)(9686003)(478600001)(55016002)(83380400001)(86362001)(316002)(107886003)(110136005)(66556008)(52536014)(66446008)(64756008)(66476007)(76116006)(26005)(71200400001)(38100700002)(66946007)(186003)(8676002)(2906002)(4326008)(122000001)(579004); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?utf-8?B?dENUVnBNSTExNTdpQ1lwTndKQlIwdUdYNys2N3ZZK3hXSy9kYUJKN0RoWHRT?= =?utf-8?B?Mnk4eWlrL2pSVTk3V2tnYW5yOFJWQ21ZTHU3bXpMWGFrRm9BaFo4S2NQYlNW?= =?utf-8?B?MzlOQ0Ntb0JZRWo5VHVEMkRyWWVlOE1ucitZc05kdnNmTEl5WG1JL0hRMmZ0?= =?utf-8?B?K1ZjTGxDUVYxZXBTUzJuZStLWTBOekFrOXp2Ty9jaTVDdWVDMFZLVXl3bjJS?= =?utf-8?B?b2NaRzZ6cXVZZmx6N1dNQUhkdXJDbjlRbGhKM2UzRTcrMk83Ry9VSFVBeUZq?= =?utf-8?B?SWpkcnRrUDZIS2k3V2RVZkxPQmpBT09Dc01SczZocWt6bzhab3k2VzY0TUJa?= =?utf-8?B?RXVOc0hHeTk3K3B6QmdkV0Q0OEpuc2YzQit2SHJrZTRtT2UzeExVY3B6T3VB?= =?utf-8?B?R0R5QUl6NG5uWFdkeEt1ZTc0TS9lQ3pyVDN0Z245TWp1dW4ybVQ0KzBtK0ZO?= =?utf-8?B?L0RuYkVTTThsVkRndHhsdVdJcHlHOE9ZRlZ0SXpLWlNydVRYYkhWM1ZqT0Zu?= =?utf-8?B?VUcwcHRUSC9TQ1kyS0Q2ZzJIVVhqUVF6REdHTDcySitGS0ZNNXdhNGw1UFBK?= =?utf-8?B?M2VOdWdVUkVhZ3ZjR2xEZ3EwWTloYStwRlVSKzVRT1BFdWFMQmZVVkppclQw?= =?utf-8?B?TnZpeXBaZVY3Y3pxZnl5YWNLY3lNOUQvTEFRV1hWcmRDdXUxYjdIT2xBSnQx?= =?utf-8?B?RjNWRVJhdFA1NU9ra2FGRHdEUzd5VWljZ3J4YnhreHMzRnhoYW43Wk1scFV4?= =?utf-8?B?TnE1K24xQThMc1lObU9leTZHaERid1lPUWowM2lobWpBYlR2UC9oM1JhVlFk?= =?utf-8?B?R3hLdUc0YU5TUjhuMVlMT1grUmlWVGg4T3FVQWtjbUtSbnA1dTBpRmdFWS9U?= =?utf-8?B?SGt4aWlSbFlRTzBCUDU3WGc5dVYwY0o3VEU2UGVuOXN4ZldnWUNPTmVpWW1n?= =?utf-8?B?aTNQeVNJTE02SDN2bHlDWHpQTWlSK3JBYWQwOFJYWUI0TmZTR1oyc3kvZHpp?= =?utf-8?B?RHhhY0taTlBRZ0Z1S0V5UC9XbW0rdjBZV0ZwSnRrS3g2NEpRdTlmMWVxV0VC?= =?utf-8?B?a1NkVzVqNnYrSkZNeUpLNEV0Qk13UjdRaUZNTjEwaG8xWEJMNmMvWHIxL3cr?= =?utf-8?B?dW03bE43YnArd3BldFg4MW9Fd0wwemxQZ29iM2xWbFdCeVV1bjU5V2U3UzZ1?= =?utf-8?B?Rm00NjREdlBNY0ZSeEplMittZlpQYlBJd1BucW1wUUhvVklMOXJZdmpyS2R5?= =?utf-8?B?ZVhld2NXaGlNMnNWYzFzc3JJOG5qT0Q1Y0d6R0VmaHRwRzRlMXZ1RDEwbG9j?= =?utf-8?B?aVdRbkhVNFhUWnNLQ3BCR1ZadlBaQlBIWStzM1lGWGtwdnRaQWxQdjZXREFZ?= =?utf-8?B?RWZXckJ4dXhJOGFiK2FWY291U3FVcmdYbWh4Ty9QeWd6YU5xb2I3MDNhdDlV?= =?utf-8?B?bUJFZkRUYkp0L0FzZHNvcjJ5MHZTdlRaM2xaL25CZ2ZmWUE5UzNjaUtVZkdk?= =?utf-8?B?bEg0THBJSzd5QW03TWNaeG9FbllhQjlLeklDM3NXbXkzM1RuN2dWWjJ1UEdm?= =?utf-8?B?b0xOblhHWHRqWDVvWlpoa0xINWdtMm5QdVR3K3FwMUMxOWd4MytQcjk5WkVZ?= =?utf-8?B?S1g3SXoreXRXaVNFMzdnbkdiSnA1ZG1XMkNSMXhJOFNsYUhlSEdkVU5pMmox?= =?utf-8?B?UWxERXdYdld1M3JqaTNqWk5jV0FXOC9ua2wxVGhhQkI2cHVTaStvakdSM2Vp?= =?utf-8?Q?PsywOijgqBrUZ3mCMbRFAMvQdzyrs+WH/HxkqDr?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: intopix.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PR3P192MB0748.EURP192.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 8cd8d0e2-8a3a-4666-6b15-08d924564bff
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2021 17:05:30.8621 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5f9168c7-cdac-4b23-9509-c278399e3c1f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 0LNZuiXDgtFsPavE3/ZJN2tOvt7SXmGZB9sbn4cUvsXWUHMfT+ubTncWrdEm6SfR
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3P192MB1087
X-MDID: 1622480733-K9vcz9OjQDEh
Archived-At: 
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 May 2021 17:05:42 -0000

T2ssIHN1cGVyLg0KDQpNYW55IHRoYW5rcyBmb3IgeW91ciBlZmZvcnQgYW5kIHRpbWUuIEkgd2ls
bCBwb3N0IHRoZSB1cGRhdGVkIGRyYWZ0IHRleHQgdG9kYXkuDQoNCkJlc3QgcmVnYXJkcywNClRp
bQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQ2hyaXN0ZXIgSG9sbWJlcmcg
PGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gDQpTZW50OiBNb25kYXkgMzEgTWF5IDIw
MjEgMTg6MjENClRvOiBUaW0gQnJ1eWxhbnRzIDxUQlJAaW50b3BpeC5jb20+OyBUaG9tYXMgUmlj
aHRlciA8dGhvbWFzLnJpY2h0ZXJAaWlzLmZyYXVuaG9mZXIuZGU+OyBhdnRAaWV0Zi5vcmcNCkNj
OiBKZWFuLUJhcHRpc3RlIExvcmVudCA8amIubG9yZW50QGludG9waXguY29tPg0KU3ViamVjdDog
UkU6IFtBVlRDT1JFXSBTRFAgZGlyZWN0b3JhdGUgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcGF5bG9h
ZC1ydHAtanBlZ3hzLTEzDQoNCkhpLA0KDQo+MSkgSSBiZWxpZXZlICIuLi4gc2VuZGluZyBjYXBh
YmlsaXRpZXMgKGkuZS4gcHJvcGVydGllcyBvZiB0aGUgcGF5bG9hZCkuLi4iIGlzIGNvcnJlY3Qu
DQo+DQo+MmEpIEknbSBub3QgMTAwJSBzdXJlIHRoYXQgSSB1bmRlcnN0YW5kIHdoYXQgeW91IG1l
YW4gYnkgdGhpcy4gTm9ybWFsbHkgSSB3b3VsZCBhc3N1bWUgdGhhdCB0aGUgc2FtZSBwYXlsb2Fk
IHR5cGUgaXMgdG8gYmUgdXNlZCBpbiBhbiBhbnN3ZXIgKHRvIHNpbXBsaWZ5IHRoaW5ncykuIEFs
bHRob3VnaCBpbiBSRkMzMjY0IHRoaXMgaXMgYSBTSE9VTEQgYW5kIG5vdCBhIE1VU1QuIFNvLCBJ
IGFkZGVkIGEgc2VudGVuY2UgdG8gYWxzbyByZWNvbW1lbmQgdGhpcy4NCg0KU29ycnkgZm9yIGJl
aW5nIHVuY2xlYXIuIEkgbWVhbnQgdGhlIG51bWVyaWMgbnVtYmVyIHZhbHVlIHRoYXQgaXMgYXNz
aWduZWQgdG8gdGhlIHBheWxvYWQuIEkgc2VlIHRoYXQgeW91IGhhdmUgY292ZXJlZCB0aGF0IG5v
dyA6KQ0KDQo+MmIpIEkgbWFkZSB0aGUgc3VnZ2VzdGVkIGNoYW5nZXMgKG9mZmVyZXIvYW5zd2Vy
ZXIpLiBJdCBpcyBnb29kIHRvIGZvbGxvdyBjb21tb24gdGVybWlub2xvZ3kuIEkgYWxzbyBhZ3Jl
ZSBhYm91dCB0aGUgVkFMVUVTIChJIHdhcyBpbiBkb3VidCB3aGVuIHdyaXRpbmcgdGhhdCBzZW50
ZW5jZSBhYm91dCB0aGlzLCBzbyBpdCdzIGdvb2QgdGhhdCB5b3UgbWVudGlvbiB0aGlzKS4NCg0K
VGhlIHRleHQgbG9va3Mgb2sgbm93Lg0KDQpUaGFua3MhDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVy
DQoNCg0KLy8tLS0gU05JUFBFVA0KOC4yLiAgVXNhZ2Ugd2l0aCBTRFAgT2ZmZXIvQW5zd2VyIE1v
ZGVsDQoNCiAgIFdoZW4gSlBFRyBYUyBpcyBvZmZlcmVkIG92ZXIgUlRQIHVzaW5nIFNEUCBpbiBh
biBvZmZlci9hbnN3ZXIgbW9kZWwNCiAgIFtSRkMzMjY0XSBmb3IgbmVnb3RpYXRpb24gZm9yIHVu
aWNhc3QgdXNhZ2UsIHRoZSBmb2xsb3dpbmcNCiAgIGxpbWl0YXRpb25zIGFuZCBydWxlcyBhcHBs
eToNCg0KICAgICAgVGhlICJhPWZtdHAiIGF0dHJpYnV0ZSBTSEFMTCBiZSBwcmVzZW50IHNwZWNp
ZnlpbmcgdGhlIHJlcXVpcmVkDQogICAgICBwYXJhbWV0ZXIgInRyYW5zbW9kZSIgYW5kIE1BWSBz
cGVjaWZ5IGFueSBvZiB0aGUgb3B0aW9uYWwNCiAgICAgIHBhcmFtZXRlcnMsIGFzIGRlc2NyaWJl
ZCBpbiBTZWN0aW9uIDcuMS4NCg0KICAgICAgQWxsIHBhcmFtZXRlcnMgaW4gdGhlICJhPWZtdHAi
IGF0dHJpYnV0ZSBpbmRpY2F0ZSBzZW5kaW5nDQogICAgICBjYXBhYmlsaXRpZXMgKGkuZS4gcHJv
cGVydGllcyBvZiB0aGUgcGF5bG9hZCkuDQoNCiAgICAgIEFuIGFuc3dlcmVyIG9mIHRoZSBTRFAg
aXMgcmVxdWlyZWQgdG8gc3VwcG9ydCBhbGwgcGFyYW1ldGVycyBhbmQNCiAgICAgIHZhbHVlcyBv
ZiB0aGUgcGFyYW1ldGVycyBwcm92aWRlZCBieSB0aGUgb2ZmZXJlcjsgb3RoZXJ3aXNlLCB0aGUN
CiAgICAgIGFuc3dlcmVyIFNIQUxMIHJlamVjdCB0aGUgc2Vzc2lvbi4gIEl0IGZhbGxzIG9uIHRo
ZSBvZmZlcmVyIHRvIHVzZQ0KICAgICAgdmFsdWVzIHRoYXQgYXJlIGV4cGVjdGVkIHRvIGJlIHN1
cHBvcnRlZCBieSB0aGUgYW5zd2VyZXIuICBJZiB0aGUNCiAgICAgIGFuc3dlcmVyIGFjY2VwdHMg
dGhlIHNlc3Npb24sIGl0IFNIQUxMIHJlcGx5IHdpdGggdGhlIGV4YWN0IHNhbWUNCiAgICAgIHBh
cmFtZXRlcnMgdmFsdWVzIGluIHRoZSAiYT1mbXRwIiBhdHRyaWJ1dGUgYXMgaXQgd2FzIG9mZmVy
ZWQuDQoNCiAgICAgIFRoZSBzYW1lIFJUUCBwYXlsb2FkIHR5cGUgbnVtYmVyIHVzZWQgaW4gdGhl
IG9mZmVyIFNIT1VMRCBiZQ0KICAgICAgdXNlZCBpbiB0aGUgYW5zd2VyLCBhcyBzcGVjaWZpZWQg
aW4gW1JGQzMyNjRdLg0KLy8tLS0gU05JUFBFVA0KDQoNCkJlc3QgcmVnYXJkcywNClRpbS4NCg0K
DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDaHJpc3RlciBIb2xtYmVyZyA8
Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KU2VudDogTW9uZGF5IDMxIE1heSAyMDIx
IDE2OjUzDQpUbzogVGltIEJydXlsYW50cyA8VEJSQGludG9waXguY29tPjsgVGhvbWFzIFJpY2h0
ZXIgPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX190
aG9tYXMucmljaHRlci00MGlpcy5mcmF1bmhvZmVyLmRlJmQ9RHdJR2FRJmM9ZXVHWnN0Y2FURGxs
dmltRU44YjdqWHJ3cU9mLXY1QV9DZHBnblZmaWlNTSZyPUxUeFVHdWtMQ0VmRVVkb19icTA0OFEm
bT10WnFoc3NiU0xaRXQ2aWM4SmhMcFlkZnU1UXNhZUFXaVFKTDBYUXNUNlBVJnM9UEJMT1hZazRs
TDhnNWdHUnpLYWUxTkRDWVpOVHh5c1NLRXhMVE1UVWNUSSZlPT47IGF2dEBpZXRmLm9yZw0KQ2M6
IEplYW4tQmFwdGlzdGUgTG9yZW50IDxqYi5sb3JlbnRAaW50b3BpeC5jb20+DQpTdWJqZWN0OiBS
RTogW0FWVENPUkVdIFNEUCBkaXJlY3RvcmF0ZSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1wYXlsb2Fk
LXJ0cC1qcGVneHMtMTMNCg0KSGkgVGltLA0KDQo+MSkgWW91IGFyZSBjb3JyZWN0IHRoYXQgdGhl
IHBhcmFtZXRlcnMgYXJlIGRlc2NyaWJpbmcgd2hhdCB0aGUgc2VuZGVyIHdpbGwgYmUgdXNpbmcg
aW4gdGhlIHBheWxvYWQgKHN0cmljdGx5IHNwZWFraW5nIHRoZXNlIGFyZSBub3QgY2FwYWJpbGl0
aWVzLCBidXQgcmF0aGVyIHN0cmljdCBwYXlsb2FkIHNldHRpbmdzIHRoYXQgd2lsbCBiZSBob25v
cmVkKS4gDQoNCkZhaXIgZW5vdWdoLiBQZXJoYXBzICJzZW5kaW5nIHByb3BlcnRpZXMiPw0KDQo+
VGhlIHJlY2VpdmVyIHNob3VsZCBiZSBhYmxlIHRvIGhhbmRsZSBzdWNoIHNldHRpbmdzIChhcyBk
ZXNjcmliZWQgYnkgdGhlc2UgcGFyYW1ldGVycykuDQo+SSB3aWxsIGFkanVzdCB0aGF0IHBhcnQg
dG8gcmVmbGVjdCB3aGF0IHlvdSBwcm9wb3NlLg0KPg0KPjIpIEkgd2lsbCBpbmRlZWQgcmVwbGFj
ZSBjcmVhdG9yL3JlY2VpdmVyIGJ5IG9mZmVyb3IvYW5zd2VyZXIgcmVzcGVjdGl2ZWx5LiBBcyBm
b3IgdGhlIGFuc3dlcmVyOiBvbiBhY2NlcHRpbmcgdGhlIGNvbm5lY3Rpb24gd2l0aCB0aGUgb2Zm
ZXJlZCBwYXJhbWV0ZXJzLCB0aGVyZSBpcyBub3QgbXVjaCB0byBzZW5kIGJhY2sgdy5yLnQuIHBh
cmFtZXRlcnMuIA0KPkJ1dCBmb3IgZWFzeSBvZiByZWNvZ25pemluZyB0aGUgbmVnb3RpYXRlZCBz
dHJlYW0sIHdlIGJlbGlldmUgdGhlIGFuc3dlcmVyIHNob3VsZCB1c2UgdGhlIHNhbWUgZm10cCAo
YXMgZ2l2ZW4gaW4gdGhlIG9mZmVyKSBpbiBpdHMgYW5zd2VyLg0KDQpEb2VzIHRoYXQgYWxzbyBp
bmNsdWRlIHRoZSBhY3R1YWwgcGF5bG9hZCB0eXBlIG51bWJlciB2YWx1ZT8NCg0KPlNvLCB1cGRh
dGVkIHRleHQgd291bGQgYmVjb21lOg0KDQpJdCBsb29rcyBvaywgYnV0IEkgc3VnZ2VzdCB0byBj
aGFuZ2U6DQoNCiJvZmZlcm9yIG9mIHRoZSBzZXNzaW9uIiAtPiAib2ZmZXJlciINCg0KImFuc3dl
cmluZyBhcHBsaWNhdGlvbiIgLT4gImFuc3dlcmVyIg0KDQouLi5iZWNhdXNlIHRoYXQgaXMgdGhl
IHRlcm1pbm9sb2d5IHdlIHVzZSB0byBpZGVudGl0eSB0aGUgZW50aXRpZXMgd2hlbiB0YWxraW5n
IGFib3V0IG9mZmVyIGFuZCBhbnN3ZXIuDQoNCkFsc28sIEkgZ3Vlc3MgeW91IHNob3VsZCBzYXkg
IlNIQUxMIHJlcGx5IHdpdGggdGhlIGV4YWN0IHNhbWUgcGFyYW1ldGVyIFZBTFVFUyBpbiB0aGUu
Li4iLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KLy8tLS0gU05JUFBFVA0KOC4yLiAg
VXNhZ2Ugd2l0aCBTRFAgT2ZmZXIvQW5zd2VyIE1vZGVsDQoNCiAgIFdoZW4gSlBFRyBYUyBpcyBv
ZmZlcmVkIG92ZXIgUlRQIHVzaW5nIFNEUCBpbiBhbiBvZmZlci9hbnN3ZXIgbW9kZWwNCiAgIFtS
RkMzMjY0XSBmb3IgbmVnb3RpYXRpb24gZm9yIHVuaWNhc3QgdXNhZ2UsIHRoZSBmb2xsb3dpbmcN
CiAgIGxpbWl0YXRpb25zIGFuZCBydWxlcyBhcHBseToNCg0KICAgICAgVGhlICJhPWZtdHAiIGF0
dHJpYnV0ZSBTSEFMTCBiZSBwcmVzZW50IHNwZWNpZnlpbmcgdGhlIHJlcXVpcmVkDQogICAgICBw
YXJhbWV0ZXIgInRyYW5zbW9kZSIgYW5kIE1BWSBzcGVjaWZ5IGFueSBvZiB0aGUgb3B0aW9uYWwN
CiAgICAgIHBhcmFtZXRlcnMsIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDcuMS4NCg0KICAgICAg
QWxsIHBhcmFtZXRlcnMgaW4gdGhlICJhPWZtdHAiIGF0dHJpYnV0ZSBpbmRpY2F0ZSBzZW5kaW5n
DQogICAgICBjYXBhYmlsaXRpZXMgKGkuZS4gcHJvcGVydGllcyBvZiB0aGUgcGF5bG9hZCkuDQoN
CiAgICAgIEFuIGFuc3dlcmVyIG9mIHRoZSBTRFAgaXMgcmVxdWlyZWQgdG8gc3VwcG9ydCBhbGwg
cGFyYW1ldGVycyBhbmQNCiAgICAgIHZhbHVlcyBvZiB0aGUgcGFyYW1ldGVycyBwcm92aWRlZCBi
eSB0aGUgb2ZmZXJvcjsgb3RoZXJ3aXNlLCB0aGUNCiAgICAgIGFuc3dlcmVyIFNIQUxMIHJlamVj
dCB0aGUgc2Vzc2lvbi4gIEl0IGZhbGxzIG9uIHRoZSBvZmZlcm9yIG9mIHRoZQ0KICAgICAgc2Vz
c2lvbiB0byB1c2UgdmFsdWVzIHRoYXQgYXJlIGV4cGVjdGVkIHRvIGJlIHN1cHBvcnRlZCBieSB0
aGUNCiAgICAgIGFuc3dlcmluZyBhcHBsaWNhdGlvbi4gIElmIHRoZSBhbnN3ZXJlciBhY2NlcHRz
IHRoZSBzZXNzaW9uLCBpdA0KICAgICAgU0hBTEwgcmVwbHkgd2l0aCB0aGUgZXhhY3Qgc2FtZSBw
YXJhbWV0ZXJzIGluIHRoZSAiYT1mbXRwIg0KICAgICAgYXR0cmlidXRlIGFzIGl0IHdhcyBvZmZl
cmVkLg0KLy8tLS0gU05JUFBFVA0KDQoNCklmIHlvdSBiZWxpZXZlIHRoaXMgaXMgb2ssIEkgd2ls
bCBwb3N0IGFuIHVwZGF0ZWQgZHJhZnQgdG8gdGhlIGRhdGF0cmFja2VyLg0KDQpCZXN0IHJlZ2Fy
ZHMsDQpUaW0uDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENocmlzdGVy
IEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpTZW50OiBNb25kYXkg
MzEgTWF5IDIwMjEgMTY6MTANClRvOiBUaW0gQnJ1eWxhbnRzIDxUQlJAaW50b3BpeC5jb20+OyBU
aG9tYXMgUmljaHRlciA8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91
PWh0dHAtM0FfX3Rob21hcy5yaWNodGVyLTQwaWlzLmZyYXVuaG9mZXIuZGUmZD1Ed0lHYVEmYz1l
dUdac3RjYVREbGx2aW1FTjhiN2pYcndxT2YtdjVBX0NkcGduVmZpaU1NJnI9TFR4VUd1a0xDRWZF
VWRvX2JxMDQ4USZtPVJkN3BFNFdFb29CcGtzWURKVHJhcDNpcjg5a1NYeGRJTkxOUFZZd2otczAm
cz1WQ3M2TUhjODBLbXN5SjBhLXJTVTRXeXlpSGVNUWkyZjVpRmlReVctQjlZJmU9PjsgYXZ0QGll
dGYub3JnDQpDYzogSmVhbi1CYXB0aXN0ZSBMb3JlbnQgPGpiLmxvcmVudEBpbnRvcGl4LmNvbT4N
ClN1YmplY3Q6IFJFOiBbQVZUQ09SRV0gU0RQIGRpcmVjdG9yYXRlIHJldmlldyBvZiBkcmFmdC1p
ZXRmLXBheWxvYWQtcnRwLWpwZWd4cy0xMw0KDQpIaSBUaW0sDQoNCj5CZWZvcmUgSSB1cGxvYWQg
YSBuZXcgZHJhZnQgdG8gYWRkcmVzcyB0aGUgU0RQLCBJIHdvdWxkIGxpa2UgeW91IHRvIHJldmlz
ZSB0aGUgZm9sbG93aW5nIHRleHQuDQo+DQo+QXMgeW91IHN0YXRlZCwgd2hlbiBkZXNjcmliaW5n
IHRoZSBTRFAgb2ZmZXIvYW5zd2VyIG1vZGVsLCB0aGUgZHJhZnQgbmVlZHMgdG8gYWRkcmVzcyB0
aGUgNSBmb2xsb3dpbmcgdG9waWNzOg0KPlguMSBHZW5lcmljIFNEUCBDb25zaWRlcmF0aW9ucw0K
PlguMi4gIEdlbmVyYXRpbmcgdGhlIEluaXRpYWwgU0RQIE9mZmVyDQo+WC4zLiAgR2VuZXJhdGlu
ZyB0aGUgU0RQIEFuc3dlcg0KPlguNC4gIE9mZmVyZXIgUHJvY2Vzc2luZyBvZiB0aGUgU0RQIEFu
c3dlciBYLjUuICBNb2RpZnlpbmcgdGhlIFNlc3Npb24NCj4NCj5PdXIgcXVlc3Rpb246IElzIHRo
aXMgc3VmZmljaWVudGx5IGRlc2NyaWJlZCBpbiBSRkMzMjY0IGFuZCBpcyBpdCBvayB0byByZWZl
ciB0byB0aGF0IFJGQyB3aXRoIHNvbWUgZXh0cmEgY2xhcmlmaWNhdGlvbnM/IFJGQzMyNjQgc2Vl
bXMgdG8gYmUgd2hhdCB3ZSBpbnRlbmQgImlmIiBzZHAgb2ZmZXIvYW5zd2VyIGlzIHVzZWQuIFRo
aXMgd291bGQgcmVzdWx0IGluIHRoZSBmb2xsb3dpbmcgdGV4dDoNCj4NCj4vLy0tLSBTTklQUEVU
DQo+OC4yLiAgVXNhZ2Ugd2l0aCBTRFAgT2ZmZXIvQW5zd2VyIE1vZGVsDQo+DQo+ICAgV2hlbiBK
UEVHIFhTIGlzIG9mZmVyZWQgb3ZlciBSVFAgdXNpbmcgU0RQIGluIGFuIG9mZmVyL2Fuc3dlciBt
b2RlbA0KPiAgIFtSRkMzMjY0XSBmb3IgbmVnb3RpYXRpb24gZm9yIHVuaWNhc3QgdXNhZ2UsIHRo
ZSBmb2xsb3dpbmcNCj4gICBsaW1pdGF0aW9ucyBhbmQgcnVsZXMgYXBwbHk6DQo+DQo+ICAgICAg
VGhlICJhPWZtdHAiIGF0dHJpYnV0ZSBTSEFMTCBiZSBwcmVzZW50IHNwZWNpZnlpbmcgdGhlIHJl
cXVpcmVkDQo+ICAgICAgcGFyYW1ldGVyICJ0cmFuc21vZGUiIGFuZCBNQVkgc3BlY2lmeSBhbnkg
b2YgdGhlDQo+ICAgICAgb3B0aW9uYWwgcGFyYW1ldGVycywgYXMgZGVzY3JpYmVkIGluIFNlY3Rp
b24gNy4xLg0KPg0KPiAgICAgIEFsbCBwYXlsb2FkIHBhcmFtZXRlcnMgYXJlIGRlY2xhcmF0aXZl
LCBtZWFuaW5nIHRoYXQgdGhleSBkZXNjcmliZQ0KPiAgICAgIHByb3BlcnRpZXMgb2YgdGhlIHBh
eWxvYWQuDQo+DQo+ICAgICAgQSByZWNlaXZlciBvZiB0aGUgU0RQIGlzIHJlcXVpcmVkIHRvIHN1
cHBvcnQgYWxsIHBhcmFtZXRlcnMgYW5kDQo+ICAgICAgdmFsdWVzIG9mIHRoZSBwYXJhbWV0ZXJz
IHByb3ZpZGVkOyBvdGhlcndpc2UsIHRoZSByZWNlaXZlciBTSEFMTA0KPiAgICAgIHJlamVjdCB0
aGUgc2Vzc2lvbi4gIEl0IGZhbGxzIG9uIHRoZSBjcmVhdG9yIG9mIHRoZSBzZXNzaW9uIHRvIHVz
ZQ0KPiAgICAgIHZhbHVlcyB0aGF0IGFyZSBleHBlY3RlZCB0byBiZSBzdXBwb3J0ZWQgYnkgdGhl
IHJlY2VpdmluZw0KPiAgICAgIGFwcGxpY2F0aW9uLg0KPi8vLS0tIFNOSVBQRVQNCj4NCj4gRmVl
ZGJhY2sgd291bGQgYmUgdmVyeSB3ZWxjb21lLg0KDQpBIGNvdXBsZSBvZiBjb21tZW50czoNCg0K
DQpRMToNCg0KIkFsbCBwYXlsb2FkIHBhcmFtZXRlcnMgYXJlIGRlY2xhcmF0aXZlLCBtZWFuaW5n
IHRoYXQgdGhleSBkZXNjcmliZSBwcm9wZXJ0aWVzIG9mIHRoZSBwYXlsb2FkLiINCg0KSSBkb24n
dCB0aGluayB5b3UgbmVlZCB0byBzYXkgdGhhdC4NCg0KQmFzZWQgb24gb3VyIGVhcmxpZXIgZGlz
Y3Vzc2lvbnMsIEkgdGhpbmsgd2hhdCB5b3UgbmVlZCB0byBwb2ludCBvdXQgaXMgdGhhdCB0aGUg
Zm10cCBhdHRyaWJ1dGUgaXMgdXNlZCB0byBpbmRpY2F0ZSBTRU5ESU5HIGNhcGFiaWxpdGllcy4N
Cg0KLS0tLQ0KDQpRMjoNCg0KIkEgcmVjZWl2ZXIgb2YgdGhlIFNEUCBpcyByZXF1aXJlZCB0byBz
dXBwb3J0IGFsbCBwYXJhbWV0ZXJzIGFuZCB2YWx1ZXMgb2YgdGhlIHBhcmFtZXRlcnMgcHJvdmlk
ZWQ7IG90aGVyd2lzZSwgdGhlIHJlY2VpdmVyIFNIQUxMIHJlamVjdCB0aGUgc2Vzc2lvbi4gIEl0
IGZhbGxzIG9uIHRoZSBjcmVhdG9yIG9mIHRoZSBzZXNzaW9uIHRvIHVzZSB2YWx1ZXMgdGhhdCBh
cmUgZXhwZWN0ZWQgdG8gYmUgc3VwcG9ydGVkIGJ5IHRoZSByZWNlaXZpbmcgYXBwbGljYXRpb24u
Ig0KDQpJbnN0ZWFkIG9mICJyZWNlaXZlciIsIEkgd291bGQgc2F5IGFuc3dlcmVyLg0KDQpJbnN0
ZWFkIG9mICJjcmVhdG9yIiwgSSB3b3VsZCBzYXkgb2ZmZXJlci4NCg0KQWxzbywgYXNzdW1pbmcg
dGhlIGFuc3dlcmVyL3JlY2VpdmVyIGFjY2VwdHMgdGhlIG9mZmVyLCB0aGVyZSBpcyBubyB0ZXh0
IG9uIHdoYXQgaXQgaW5jbHVkZXMgaW4gdGhlIGFuc3dlci4gRG9lcyB0aGUgYW5zd2VyZXIgYWxz
byBpbmNsdWRlIGFuIGZtdHAgYXR0cmlidXRlPyBJZiBzbywgd2hhdCB2YWx1ZXMgZG9lcyBpdCBp
bmNsdWRlPw0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KRnJvbTogYXZ0IDxhdnQtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9m
IFRpbSBCcnV5bGFudHMNClNlbnQ6IEZyaWRheSAyOCBNYXkgMjAyMSAxMjoyMQ0KVG86IENocmlz
dGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+OyBUaG9tYXMgUmlj
aHRlciA8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0Ff
X3Rob21hcy5yaWNodGVyLTQwaWlzLmZyYXVuaG9mZXIuZGUmZD1Ed0lHYVEmYz1ldUdac3RjYVRE
bGx2aW1FTjhiN2pYcndxT2YtdjVBX0NkcGduVmZpaU1NJnI9TFR4VUd1a0xDRWZFVWRvX2JxMDQ4
USZtPVB2SUtub3kySVJNUl9aeWpRR0RmWG9GQXVaWkpWdTJMRWEzN0NIR2xpRzAmcz1nTF85MWh3
dzJDdGZoU0NhUXJiSlR1YlVPMUtlY2pOdEZGX3c5V09SRDVnJmU9PjsgYXZ0QGlldGYub3JnDQpD
YzogSmVhbi1CYXB0aXN0ZSBMb3JlbnQgPGpiLmxvcmVudEBpbnRvcGl4LmNvbT4NClN1YmplY3Q6
IFJlOiBbQVZUQ09SRV0gU0RQIGRpcmVjdG9yYXRlIHJldmlldyBvZiBkcmFmdC1pZXRmLXBheWxv
YWQtcnRwLWpwZWd4cy0xMw0KDQpIaSBDaHJpc3RlciwNCg0KVGhhbmtzIGZvciB0aGUgcXVpY2sg
cmVzcG9uc2UsIHdlIHJlYWxseSBhcHByZWNpYXRlIHlvdXIgdGltZS4NCg0KU28sIGxldCBtZSBl
bGFib3JhdGUgYSBiaXQ6DQoNCj4+IEZpcnN0LCByZWdhcmRpbmcgUkZDIDg0NTAsIHRoYXQgc3Bl
Y2lmaWNhdGlvbiB3YXMgcHJvYmFibHkgbmV2ZXIgcmV2aWV3ZWQgYnkgdGhlIFNEUCBkaXJlY3Rv
cmF0ZSwgc28gSSBjYW4ndCByZWFsbHkgY29tbWVudCBvbiB0aGF0LiBCdXQsIEkgc2VlIHRoYXQg
dGhlIFJGQyBlLmcuLCBzYXlzIG5vdGhpbmcgYWJvdXQgd2hldGhlciB0aGUgU0RQIGluZGljYXRl
cyBzZW5kaW5nIG9yIHJlY2VpdmluZyBjYXBhYmlsaXRpZXMuDQoNCk9rLCBJIHVuZGVyc3RhbmQg
dGhhdCBSRkMgODQ1MCBtaWdodCBub3QgYmUgZW50aXJlbHkgY2xlYXIgb3Igd2VsbCB3cml0dGVu
IG9uIHRoZSBTRFAgcGFydC4NCg0KPj4gU2Vjb25kLCBub2JvZHkgbWFuZGF0ZXMgeW91IHRvIHVz
ZSBTRFAsIGFuZCBtb3N0IHBhcnQgb2YgdGhlIHNwZWMgaXMgcHJvdG9jb2wgaW5kZXBlbmRlbnQu
IEJ1dCwgdGhlICJTRFAgT2ZmZXIvQW5zd2VyIiBzZWN0aW9uIGRlc2NyaWJlcyB0aGUgU0RQIG9m
ZmVyL2Fuc3dlciBwcm9jZWR1cmVzLCAqSUYqIHlvdSBjaG9vc2UgdG8gdXNlIHRoYXQgbWVjaGFu
aXNtIGZvciBuZWdvdGlhdGluZyB0aGUgc2Vzc2lvbi4NCg0KT2suIFRoYXQgSSB1bmRlcnN0YW5k
LiBJbiBvdXIgY2FzZSwgU0RQIGFzIHRoZSBzZXNzaW9uIHByb3RvY29sIGlzIG5vdCBjcml0aWNh
bCwgYnV0IHN0aWxsIGEgbmljZSB0byBoYXZlLiBEbyB5b3UgYWdyZWU/IE9yIGRvIHlvdSByZWNv
bW1lbmQgd2UgcmVtb3ZlIHRoZSBTRFAgb2ZmZXIvYW5zd2VyIHNlY3Rpb24/DQoNCldoYXQgd2Ug
ZG8gbmVlZCB0byBzYXkgaXMgaG93IHRvIG1hcCBwYXJhbWV0ZXJzIGludG8gYW4gU0RQLWNvbXBs
aWFudCBmb3JtYXQgZGVzY3JpcHRpb24sIGZvciB0aGUgc2FtZSByZWFzb25zIGFzIFJGQyA4NDUw
IGFuZCBtYW55IG90aGVyIHZpZGVvIHBheWxvYWQgUkZDJ3MgKFZQOCwgVlA5LCBILjI2NC9BVkMs
IEguMjY1L0hFVkMsIGV0YykuIFRoaXMgYWxsb3dzIHVzaW5nIG1hbnkgb3RoZXIgc2Vzc2lvbiBu
ZWdvdGlhdGlvbiBwcm90b2NvbHMgdGhhdCByZWx5IG9uIHRoZSBTRFAgZGVzY3JpcHRpb24uDQoN
Cj4+IFRoaXJkIC4uLi4NCg0KSSBiZWxpZXZlIHdoYXQgaXMgdmVyeSBpbXBvcnRhbnQgdG8gZXhw
bGFpbiBpcyB0aGF0IGFsbCBvZiBvdXIgcGFyYW1ldGVycyBhcmUgZGVjbGFyYXRpdmUsIG1lYW5p
bmcgdGhhdCB0aGV5IGRlc2NyaWJlIGV4YWN0IGJpdHN0cmVhbSBwcm9wZXJ0aWVzLCBhbmQgbm90
IHJlY2VpdmVyIGNhcGFiaWxpdGllcy4gVGhlIFNEUCBwYXJhbWV0ZXJzIGNhbiBiZSB1c2VkIHRv
IGNvbW11bmljYXRlIGJldHdlZW4gc2VuZGVyL3JlY2VpdmVyIHdoYXQgdGhleSB3aXNoIHRvIGV4
Y2hhbmdlIGJlZm9yZSBzZW5kaW5nIGFjdHVhbCBwYXlsb2FkLCBidXQgbm9uZSBvZiB0aGVzZSBw
YXJhbWV0ZXJzIG9yIHZhbHVlcyBhcmUgImRvd25ncmFkYWJsZSIgb3IgImluY2x1c2l2ZSBjYXBh
YmlsaXR5IHNldHMiLiBYUyBkb2VzIG5vdCBoYXZlIHN1Y2ggY29uY2VwdHMsIGFzIGl0IGlzIGEg
bG93LWNvbXBsZXhpdHkgY29kZWMsIGludGVuZGVkIHByaW1hcmlseSB0byByZXBsYWNlIHVuY29t
cHJlc3NlZCB2aWRlbyBzdHJlYW1zLg0KDQpTb21laG93LCB0aGlzIHJhaXNlcyB0aGUgZm9sbG93
aW5nOg0KDQpYLjEgR2VuZXJpYyBTRFAgQ29uc2lkZXJhdGlvbnMNCiAgSSBiZWxpZXZlIGhlcmUg
d2UgZXhwbGFpbiB0aGF0IHBhcmFtZXRlcnMgYXJlIGRlY2xhcmF0aXZlIGFuZCByZXByZXNlbnQg
Yml0c3RyZWFtL3BheWxvYWQgdmFsdWVzL3NldHRpbmdzLiBTbyBib3RoIHNpZGVzIGNhbiB1c2Ug
dGhlc2UgdG8gaW5kaWNhdGUgd2hhdCB0aGUgcGF5bG9hZCB3aWxsIGxvb2sgbGlrZS4NCg0KWC4y
LiAgR2VuZXJhdGluZyB0aGUgSW5pdGlhbCBTRFAgT2ZmZXINCiAgTm90IG11Y2ggdG8gc2F5IGhl
cmUuIEFzIEkgdW5kZXJzdGFuZCBhbiBTRFAgc2Vzc2lvbiBjYW4gYmUgaW5pdGlhdGVkIGZyb20g
ZWl0aGVyIHJlY2VpdmVyIG9yIHNlbmRlciBzaWRlcz8gU28sIHRoZXkganVzdCBzZW5kIGEgdmFs
aWQgbWVkaWEgZGVzY3JpcHRpb24gb2YgdGhlIGNvbnRlbnQgdGhleSB3YW50IHRvIGV4Y2hhbmdl
LiBJZiBlaXRoZXIgc2lkZSBjYW5ub3QgaGFuZGxlIGNlcnRhaW4gcGF5bG9hZCBzZXR0aW5ncywg
dGhlbiBpdCBzaG91bGQgcmVqZWN0IHRoZSBvZmZlciAob3IgYW5zd2VyKS4gQW4gb2ZmZXJlciBq
dXN0IHNlbmRzIHdoYXQgaXQgd2FudHMgdG8gcmVjZWl2ZSBvciBzZW5kLg0KDQpYLjMuICBHZW5l
cmF0aW5nIHRoZSBTRFAgQW5zd2VyDQogIEkgZG9uJ3QgdGhpbmsgdGhlcmUgaXMgYW55dGhpbmcg
c3BlY2lhbCB0byBtZW50aW9uIGhlcmU/IFRoZSBhbnN3ZXJlciB0YWtlcyB0aGUgZGVjbGFyYXRp
dmUgcGFyYW1ldGVycyBhbmQgZWl0aGVyIGFjY2VwdHMgb3IgcmVqZWN0cyB0aGUgc2Vzc2lvbi4g
SXQgc2hvdWxkIE5PVCBtb2RpZnkgdGhlIG9mZmVyIGluIGFueSB3YXkuDQoNClguNC4gIE9mZmVy
ZXIgUHJvY2Vzc2luZyBvZiB0aGUgU0RQIEFuc3dlcg0KICBJIGRvbid0IHRoaW5rIHRoZXJlIGlz
IGFueXRoaW5nIHNwZWNpYWwgdG8gbWVudGlvbiBoZXJlPyBJZiB0aGUgYW5zd2VyIGFjY2VwdGVk
IHRoZSBvZmZlciwgdGhlbiB0aGUgc3RyZWFtIGNhbiBzdGFydC4NCg0KWC41LiAgTW9kaWZ5aW5n
IHRoZSBTZXNzaW9uDQogIE1vZGlmeWluZyB0aGUgc2Vzc2lvbiBpcyBwb3NzaWJsZSwgYnV0IHRo
aXMgaXMgdmVyeSBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYy4gQmFzaWNhbGx5LCBtb2RpZnlpbmcg
YSBzZXNzaW9uIGlzIHZlcnkgc2ltaWxhciB0byBjcmVhdGlvbiBvZiBhIG5ldyBzZXNzaW9uLiBC
b3RoIHNpZGVzIHNob3VsZCBhZ3JlZSBvbiB0aGUgcGF5bG9hZCB0aGV5IHdpbGwgZXhjaGFuZ2Uu
DQoNCg0KSSdtIHNvcnJ5IHRvIGRyYWcgdGhpcyBvdXQsIGJ1dCBJIHRoaW5rIHRoYXQgaGF2aW5n
IHRoaXMgY29udmVyc2F0aW9uIGJ5IGVtYWlsIGlzIG1vcmUgZWZmaWNpZW50IHRoYW4gcG9zdGlu
ZyBkcmFmdHMg8J+YiiBJIGFwcHJlY2lhdGUgeW91ciBmZWVkYmFjay4NCg0KVGltLg0KDQoNCi0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0
ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KU2VudDogRnJpZGF5IDI4IE1heSAyMDIxIDEwOjM5
DQpUbzogVGltIEJydXlsYW50cyA8VEJSQGludG9waXguY29tPjsgVGhvbWFzIFJpY2h0ZXIgPGh0
dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX190aG9tYXMu
cmljaHRlci00MGlpcy5mcmF1bmhvZmVyLmRlJmQ9RHdJR2FRJmM9ZXVHWnN0Y2FURGxsdmltRU44
YjdqWHJ3cU9mLXY1QV9DZHBnblZmaWlNTSZyPUxUeFVHdWtMQ0VmRVVkb19icTA0OFEmbT1WdnNh
N3VGQTV6MERXbkJTb05FbnZhXzRpajVyYmNRR093THBfaS0zejd3JnM9YXVlSmlvVGx0WTA1a3hm
QjIxUkZPdlNRc3o4bHVsVG95WFF6YmN0SkN2YyZlPT47IGF2dEBpZXRmLm9yZw0KQ2M6IEplYW4t
QmFwdGlzdGUgTG9yZW50IDxqYi5sb3JlbnRAaW50b3BpeC5jb20+DQpTdWJqZWN0OiBSRTogW0FW
VENPUkVdIFNEUCBkaXJlY3RvcmF0ZSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1q
cGVneHMtMTMNCg0KSGksDQoNCkZpcnN0LCByZWdhcmRpbmcgUkZDIDg0NTAsIHRoYXQgc3BlY2lm
aWNhdGlvbiB3YXMgcHJvYmFibHkgbmV2ZXIgcmV2aWV3ZWQgYnkgdGhlIFNEUCBkaXJlY3RvcmF0
ZSwgc28gSSBjYW4ndCByZWFsbHkgY29tbWVudCBvbiB0aGF0LiBCdXQsIEkgc2VlIHRoYXQgdGhl
IFJGQyBlLmcuLCBzYXlzIG5vdGhpbmcgYWJvdXQgd2hldGhlciB0aGUgU0RQIGluZGljYXRlcyBz
ZW5kaW5nIG9yIHJlY2VpdmluZyBjYXBhYmlsaXRpZXMuDQoNClNlY29uZCwgbm9ib2R5IG1hbmRh
dGVzIHlvdSB0byB1c2UgU0RQLCBhbmQgbW9zdCBwYXJ0IG9mIHRoZSBzcGVjIGlzIHByb3RvY29s
IGluZGVwZW5kZW50LiBCdXQsIHRoZSAiU0RQIE9mZmVyL0Fuc3dlciIgc2VjdGlvbiBkZXNjcmli
ZXMgdGhlIFNEUCBvZmZlci9hbnN3ZXIgcHJvY2VkdXJlcywgKklGKiB5b3UgY2hvb3NlIHRvIHVz
ZSB0aGF0IG1lY2hhbmlzbSBmb3IgbmVnb3RpYXRpbmcgdGhlIHNlc3Npb24uDQoNClRoaXJkLCBJ
IGRvbid0IHRoaW5rIHlvdSBuZWVkIHZlcnkgbXVjaCB0ZXh0LiBUaGUgaW1wb3J0YW50IHRoaW5n
IGlzIHRvIHNheSB3aGF0IGlzIHBsYWNlZCBpbiBvZmZlcnMgYW5kIGFuc3dlcnMsIHdoZXRoZXIg
dGhlcmUgYXJlIGNvbnN0cmFpbnRzIHdoZW4gZ2VuZXJhdGluZyB0aGUgYW5zd2VyLCBhbmQgd2hl
dGhlciB0aGVyZSBhcmUgY29uc3RyYWludHMgd2hlbiBpdCBjb21lcyB0byBtb2RpZnlpbmcgdGhl
IHNlc3Npb24uIEFuZCwgeW91IGRvIE5PVCAgbmVlZCB0byBzcGVjaWZ5IEhPVyB0byBtb2RpZnkg
YSBzZXNzaW9uLCBidXQgd2hldGhlciB0aGVyZSBhcmUgcGF5bG9hZC1zcGVjaWZpYyBjb25zdHJh
aW50cyB3aGVuIGRvaW5nLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQotLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KRnJvbTogVGltIEJydXlsYW50cyA8VEJSQGludG9waXguY29tPg0KU2Vu
dDogcGVyamFudGFpIDI4LiB0b3Vrb2t1dXRhIDIwMjEgOS40OQ0KVG86IENocmlzdGVyIEhvbG1i
ZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+OyBUaG9tYXMgUmljaHRlciA8aHR0
cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3Rob21hcy5y
aWNodGVyLTQwaWlzLmZyYXVuaG9mZXIuZGUmZD1Ed0lGQWcmYz1ldUdac3RjYVREbGx2aW1FTjhi
N2pYcndxT2YtdjVBX0NkcGduVmZpaU1NJnI9TFR4VUd1a0xDRWZFVWRvX2JxMDQ4USZtPWdmQjRQ
Ri12VkJXLUhWeGNTeEN4MDdMQ2hRMUNTZXBZTjNKbnV2UFp2aGcmcz1XZzA4aTMyMTNiQ3lQMFli
OEhqNWlocEJXai1kbHJWbktEZGpnZ09KYnFBJmU9PjsgYXZ0QGlldGYub3JnDQpDYzogSmVhbi1C
YXB0aXN0ZSBMb3JlbnQgPGpiLmxvcmVudEBpbnRvcGl4LmNvbT4NClN1YmplY3Q6IFJFOiBbQVZU
Q09SRV0gU0RQIGRpcmVjdG9yYXRlIHJldmlldyBvZiBkcmFmdC1pZXRmLXBheWxvYWQtcnRwLWpw
ZWd4cy0xMw0KDQpIaSBDaHJpc3RlciwNCg0KSSdtIGEgbGl0dGxlIGJpdCBzdHVjayBpbiBob3cg
dG8gcmVzb2x2ZSBhbmQgYWRkcmVzcyB5b3VyIGNvbW1lbnRzLiBPbiBvbmUgaGFuZCBJIHVuZGVy
c3RhbmQgdGhhdCB3ZSB3YW50IHRoZSB0ZXh0IHRvIGJlIGNsZWFyLCBidXQgb24gdGhlIG90aGVy
IGhhbmQgd2UgZG8gbm90IHdhbnQgdG8gcmVwZWF0IFNEUCBzcGVjaWZpY3MgdG9vIG11Y2guIFNE
UCBpcyBqdXN0IG9uZSB3YXkgdG8gbmVnb3RpYXRlIGEgc2Vzc2lvbiwgYW5kIGluIHRoZSBjYXNl
IG9mIFhTIGl0IGlzIG5vdCB0aGUgbW9zdCBjb21tb25seSB1c2VkIG9uZS4gWFMgaXMgbm90IHJl
YWxseSBpbnRlbmRlZCBmb3IgdGhlIGNsYXNzaWNhbCB2aWRlby1jYWxsIGNhc2UsIGJ1dCByYXRo
ZXIgdG8gc3RyZWFtIGhpZ2gtcXVhbGl0eSB2aWRlbyBjb250ZW50IGluIGEgcHJvZmVzc2lvbmFs
IGVudmlyb25tZW50LiBJdCBjYW4gYmUgdXNlZCBmb3IgdmlkZW8gY29uZmVyZW5jaW5nLCBidXQg
YmV0dGVyIHN1aXRlZCBjb2RlY3MgZXhpc3QgZm9yIHRoYXQgdXNlLWNhc2UuDQoNCkhvd2V2ZXIs
IHdoYXQgaXMgaW1wb3J0YW50IHRvIGxheSBvdXQgY29ycmVjdGx5IGlzIHRoZSBtYXBwaW5nIG9m
IHRoZSBtZWRpYSBwYXJhbWV0ZXJzIGludG8gdGhlIGE9Zm10cCBmaWVsZCBvZiBTRFAsIGJlY2F1
c2UgdGhpcyBpcyBhY3R1YWxseSB1c2VkIGJ5IG1hbnkgb3RoZXIgcHJvdG9jb2xzIChzbywganVz
dCB0aGUgbWVkaWEgZGVzY3JpcHRpb24gcGFydCBvZiBTRFAgaXMgdXNlZCkuDQoNCk9yaWdpbmFs
bHksIHdlIGJhc2VkIG91ciBkcmFmdCB0ZXh0IG9uIFJGQyA4NDUwIChWQy0yIEhRIFJUUCBQYXls
b2FkKS4gSW4gdGhhdCByZXNwZWN0LCB3aGF0IGlzIHdyaXR0ZW4gdGhlcmUga2luZCBvZiBmaXRz
IGV4YWN0bHkgd2hhdCB3ZSB3YW50IHdpdGggWFMuIEdpdmVuIHRoYXQgdGhpcyBpcyBhIHB1Ymxp
c2hlZCBSRkMsIHdlIGFyZSBwdXp6ZWxlZCBhIGJpdCBhcyB0byB3aHkgb3VyIGRyYWZ0IHdvdWxk
IG5lZWQgdG8gZWxhYm9yYXRlIHNvIGV4dGVuc2l2ZWx5IG9uIFNEUC4gRm9yIHN1cmUsIHdlJ2Qg
bGlrZSB0byBhbGxvdyBTRFAgb2ZmZXIvYW5zd2VyIG5lZ290aWF0aW9uIHdpdGggWFMuIEJ1dCB0
aGlzIGlzIHZlcnkgc2ltcGxlOiBlYWNoIHNpZGUgdGVsbHMgdGhlIG90aGVyIHNpZGUgd2hhdCBp
dCBzdXBwb3J0cywgYW5kIHRoYXQncyBpdC4gSW4gWFMgdGhlIHBhcmFtZXRlcnMgYXJlIGRlY2xh
cmF0aXZlLCBtZWFuaW5nIChhdCBsZWFzdCB0aGF0J3Mgd2hhdCB3ZSB3YW50IHRvIGV4cHJlc3Mp
IHRoYXQgZWFjaCBwYXJhbWV0ZXIgaXMgcmVwcmVzZW50cyBhbiBleGFjdCB2YWx1ZSBhbmQgaXMg
bm90ICJpbmNsdXNpdmUiIGludG8gYSByYW5nZSBvZiBsZXNzZXIgdmFsdWVzLiBJbiBvdGhlciB3
b3JkcywgdGhlIG90aGVyIHNpZGUgY2Fubm90IGV4cGVjdCB0aGF0IGEgImxlc3NlciIgdmFsdWUg
b2YgYSBwYXJhbWV0ZXIgY2FuIHdvcmsuDQoNCllvdXIgcHJvcG9zZWQgc3RydWN0dXJlIGlzIGp1
c3QgdG8gZWxhYm9yYXRlIGFuZCBvdXQgb2Ygc2NvcGUuIEFzIHN1Y2gsIEkgd291bGQgYXNrIHlv
dSB0byBjb25zaWRlciB0aGUgZXhhbXBsZSBvZiBSRkMgODQ1MCAod2hlcmUgdGhlIHVzZS1jYXNl
IGFuZCBwdXJwb3NlIG1hdGNoZXMgdGhhdCBvZiBvdXIgZHJhZnQpLiBGb3IgZXhhbXBsZTogV2h5
IGRvIHdlIG5lZWQgdG8gc3RhdGUgYW55dGhpbmcgc3BlY2lmaWMgb24gIk1vZGlmeWluZyB0aGUg
U2Vzc2lvbiI/IElzbid0IHRoaXMgbGF5ZWQgb3V0IGJ5IFNEUCBvbiBob3cgdG8gbW9kaWZ5IGEg
c2Vzc2lvbj8gVGhlcmUncyBub3RoaW5nIHNwZWNpZmljIHRvIGJlIHB1dCBpbiBvdXIgZHJhZnQg
KHdlIGRvIG5vdCB3YW50IHRvIHByZXZlbnQsIG5vdCBzdWdnZXN0IHRoaXMgZnVuY3Rpb25hbGl0
eSkuDQoNCkkgaG9wZSB5b3UgY2FuIHVuZGVyc3RhbmQgb3VyIGRpZmZpY3VsdHkgd2l0aCB5b3Vy
IHJlbWFya3MgYW5kIGNvbW1lbnRzLiBPdXIgcHJvcG9zYWwgYXMgc3VjaCBpcyB0byBrZWVwIHRo
ZSB0ZXh0IGFib3V0IFNEUCB2ZXJ5IHNob3J0IGFuZCBzaW1wbGUuIFRoZSBSVFAgUGF5bG9hZCBk
cmFmdCBjYW4gYmUgdXNlZCB3aXRoIFNEUCwgYnV0IGl0J3MgY2VydGFpbmx5IG5vdCB0aGUgb25s
eSB3YXkuDQoNCkkgd2lsbCBiZSBwcmVwYXJpbmcgYW4gdXBkYXRlZCBkcmFmdCB3aGljaCB0cmll
cyB0byBiZSB2ZXJ5IG1pbmltYWwgb24gdGhlIFNEUCBzcGVjaWZpY3MuIFVubGVzcyBhbnl0aGlu
ZyBpcyB0ZWNobmljYWxseSB3cm9uZywgSSByZWFsbHkgaG9wZSB5b3UgY2FuIGFncmVlIHRvIGl0
IGFuZCBtb3ZlIGZvcndhcmQgd2l0aCB0aGUgcHVibGljYXRpb24gcHJvY2Vzcy4NCg0KQmVzdCBy
ZWdhcmRzLA0KVGltLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBhdnQg
PGF2dC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIgSG9sbWJlcmcNClNl
bnQ6IFdlZG5lc2RheSAyNiBNYXkgMjAyMSAxODo0Mw0KVG86IFRob21hcyBSaWNodGVyIDxodHRw
czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fdGhvbWFzLnJp
Y2h0ZXItNDBpaXMuZnJhdW5ob2Zlci5kZSZkPUR3SUZBZyZjPWV1R1pzdGNhVERsbHZpbUVOOGI3
alhyd3FPZi12NUFfQ2RwZ25WZmlpTU0mcj1MVHhVR3VrTENFZkVVZG9fYnEwNDhRJm09Z2ZCNFBG
LXZWQlctSFZ4Y1N4Q3gwN0xDaFExQ1NlcFlOM0pudXZQWnZoZyZzPVdnMDhpMzIxM2JDeVAwWWI4
SGo1aWhwQldqLWRsclZuS0RkamdnT0picUEmZT0+OyBhdnRAaWV0Zi5vcmcNClN1YmplY3Q6IFJl
OiBbQVZUQ09SRV0gU0RQIGRpcmVjdG9yYXRlIHJldmlldyBvZiBkcmFmdC1pZXRmLXBheWxvYWQt
cnRwLWpwZWd4cy0xMw0KDQpUaGlzIGlzIGEgc3RydWN0dXJlIHRoYXQgaXMgdHlwaWNhbGx5IHVz
ZWQgZm9yIFNEUCBvZmZlci9hbnN3ZXIgcHJvY2VkdXJlczoNCg0KWC4gIFNEUCBPZmZlci9BbnN3
ZXIgUHJvY2VkdXJlcw0KICAgICBYLjEuICBHZW5lcmljIFNEUCBDb25zaWRlcmF0aW9ucw0KCTxI
ZXJlIHlvdSBjYW4gZGVzY3JpYmUgdGhpbmdzIHdoaWNoIGFwcGx5IHRvIGJvdGggb2ZmZXJzIGFu
ZCBhbnN3ZXJzPg0KICAgICBYLjIuICBHZW5lcmF0aW5nIHRoZSBJbml0aWFsIFNEUCBPZmZlcg0K
CTxIZXJlIHlvdSBkZXNjcmliZSBob3cgdGhlIGluaXRpYWwgU0RQIG9mZmVyIGZvciB0aGUgc2Vz
c2lvbiBpcyBnZW5lcmF0ZWQ+DQogICAgIFguMy4gIEdlbmVyYXRpbmcgdGhlIFNEUCBBbnN3ZXIN
Cgk8SGVyZSB5b3UgZGVzY3JpYmUgaG93IHRoZSBhbnN3ZXJlciBnZW5lcmF0ZXMgdGhlIFNEUCBh
bnN3ZXIsIGluY2x1ZGluZyB3aGV0aGVyIHBhcmFtZXRlcnMvcGFyYW1ldGVyIHZhbHVlcyBuZWVk
IHRvIGJlIGEgc3Vic2V0IG9mIHRoZSBwYXJhbWV0ZXJzL3BhcmFtZXRlciB2YWx1ZXMgaW4gdGhl
IG9mZmVyIGV0Yz4NCiAgICAgWC40LiAgT2ZmZXJlciBQcm9jZXNzaW5nIG9mIHRoZSBTRFAgQW5z
d2VyDQogICAgIDcuNS4gIE1vZGlmeWluZyB0aGUgU2Vzc2lvbg0KCTxIZXJlIHlvdSBkZXNjcmli
ZSBjb25zdHJhaW50cyByZWxhdGVkIHRvIG1vZGlmaWNhdGlvbiBvZiB0aGUgc2Vzc2lvbiwgaW5j
bHVkaW5nIHdoZXRoZXIgdGhlcmUgYXJlIGNlcnRhaW4gcGFyYW1ldGVycy9wYXJhbWV0ZXIgdmFs
dWVzIHRoYXQgeW91IGNhbm5vdCBtb2RpZnkgZXRjPg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K
DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogYXZ0IDxhdnQtYm91bmNlc0BpZXRm
Lm9yZz4gT24gQmVoYWxmIE9mIENocmlzdGVyIEhvbG1iZXJnDQpTZW50OiBrZXNraXZpaWtrbyAy
Ni4gdG91a29rdXV0YSAyMDIxIDE5LjM4DQpUbzogVGhvbWFzIFJpY2h0ZXIgPGh0dHBzOi8vdXJs
ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX190aG9tYXMucmljaHRlci00
MGlpcy5mcmF1bmhvZmVyLmRlJmQ9RHdJQ0FnJmM9ZXVHWnN0Y2FURGxsdmltRU44YjdqWHJ3cU9m
LXY1QV9DZHBnblZmaWlNTSZyPUxUeFVHdWtMQ0VmRVVkb19icTA0OFEmbT1MdGVmUWlMaGRyWHdV
eWNhaDdabXNheWtfZHRIRi1oTUVCd0hvNkRwZXQwJnM9LVRPMVFmN2wxX3FjNGtsUkt2YnVXOF9l
RDRMOGY4NU9CNURhaGIyTFFHRSZlPT47IGF2dEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtBVlRD
T1JFXSBTRFAgZGlyZWN0b3JhdGUgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtanBl
Z3hzLTEzDQoNCkhpLA0KDQo+PiBVbmZvcnR1bmF0ZWx5IEkgZG9uJ3QgdGhpbmsgd2hhdCB5b3Ug
ZXhwbGFpbiBhYm92ZSBpcyB2ZXJ5IGNsZWFyIGluIA0KPj4gdGhlIHRleHQuDQo+PiANCj4+IENv
bnNpZGVyIHRoZSBmb2xsb3dpbmcuDQo+PiANCj4+IFRoZSBvZmZlcmVyIHNlbmRzIGFuIG9mZmVy
LiBUaGUgb2ZmZXJlciBzcGVjaWZpZXMgdGhlIGNoYXJhY3RlcmlzdGljcyANCj4+IHRoYXQgdGhl
IG9mZmVyZXIgd2FudHMgdG8gcmVjZWl2ZS4gU2ltaWxhcmx5LCB0aGUgYW5zd2VyIHNwZWNpZmll
cyANCj4+IHRoZSBjaGFyYWN0ZXJpc3RpY3MgdGhhdCB0aGUgYW5zd2VyZXIgd2FudHMgdG8gcmVj
ZWl2ZSAtIHRoZSBhbnN3ZXJlciANCj4+IGRvZXMgTk9UIHNwZWNpZnkgd2hhdCBpdCBpcyBnb2lu
ZyB0byBzZW5kLiB3aGljaCBJIHRoaW5rIHRoZSB0ZXh0IGlzIA0KPj4gY3VycmVudGx5IGRlc2Ny
aWJpbmcuDQo+DQo+IFNvcnJ5IHRvIHNvdW5kIGNvbmZ1c2VkLCBidXQgbWF5YmUgeW91IGNvdWxk
IGV4cGxhaW4gYSBiaXQgYmV0dGVyLiBUbyBteSB1bmRlcnN0YW5kaW5nLCBpdCBpcyB0aGUgb2Zm
ZXJlciB0aGF0IGRlc2NyaWJlcyB3aGF0IGl0IG9mZmVycyB0byBzZW5kLCBhbmQgbm90IHRoZSBv
dGhlciB3YXkgYXJvdW5kPyANCj4gTWF5YmUgSSBtaXN1bmRlcnN0YW5kIHNvbWV0aGluZyB2ZXJ5
IGZ1bmRhbWVudGFsPyBTb3JyeSB0byBhc2sgdGhlc2UgZWxlbWVudGFyeSBxdWVzdGlvbnMsIGJ1
dCB0aGlzIGlzIGltcG9ydGFudCBmb3IgdGhlIHRleHQuDQoNCkluIFNEUCBPZmZlci9BbnN3ZXIs
IHRoZSBkZWZhdWx0IGlzIHRvIGluZGljYXRlIHdoYXQgeW91IGFyZSB3aWxsaW5nIHRvIFJFQ0VJ
VkUgOikNCg0KVHlwaWNhbGx5IHlvdXIgcmVjZWl2aW5nIGNhcGFiaWxpdGllcyBhbHNvIGltcGxp
Y2l0bHkgaW5kaWNhdGUgd2hhdCB5b3UgYXJlIGFibGUgdG8gc2VuZC4gRm9yIGV4YW1wbGUsIGlm
IEkgYW0gaW5kaWNhdGluZyB0aGF0IEkgYW0gd2lsbGluZyB0byByZWNlaXZlIGNvZGVjIFggaXQg
bm9ybWFsbHkgbWVhbnMgdGhhdCBJIGFtIGFsc28gYWJsZSB0byBzZW5kIGNvZGVjIFguDQoNCiBC
dXQsIHRoZXJlIGFyZSBjYXNlcyB3aGVyZSB0aGF0IGlzIG5vdCB0cnVlLCBlc3BlY2lhbGx5IHdo
ZW4gaXQgY29tZXMgdG8gdmlkZW8gY29kZXMgd2hlcmUgeW91IHR5cGljYWxseSBoYXZlIG1vcmUg
cGFyYW1ldGVycyBhc3NvY2lhdGVkIHdpdGggdGhlIGNvZGVjLCBhbmQgb25lIG5lZWRzIHRvIGV4
cGxpY2l0bHkgaW5kaWNhdGUgc2VuZGluZyBjYXBhYmlsaXRpZXMuIA0KDQotLS0NCg0KPj4gIlRo
ZSByZWNlaXZlciBTSEFMTCBpZ25vcmUgYW55IHVucmVjb2duaXplZCBwYXJhbWV0ZXIgb3IgaW52
YWxpZCANCj4+IHBhcmFtZXRlciB2YWx1ZS4iDQo+PiANCj4+IEZpcnN0LCBJbiBteSBvcGluaW9u
IGludmFsaWQgcGFyYW1ldGVycyB2YWx1ZXMgc2hhbGwgdHJpZ2dlciBhbiBlcnJvci4NCj4+IA0K
Pj4gU2Vjb25kLCB3aGF0IGlzIGFuIHVucmVjb2duaXplZCBwYXJhbWV0ZXI/DQo+DQo+IEkgd29u
ZGVyIHdoeSB3ZSBuZWVkIHRvIHNwZWNpZnkgdGhpcywgaS5lLiB3aGF0IGEgcmVjZWl2ZSBkb2Vz
IGFib3V0IA0KPiBwYXJhbWV0ZXJzIGl0IGRvZXMgbm90IHJlY29nbml6ZT8gRXNzZW50aWFsbHks
IHRoaXMgaXMgYSBwcm9ibGVtIG9mIA0KPiAiZm9yZXdhcmQgY29tcGF0aWJpbGl0eSIuIFdvdWxk
bid0IGl0IGJlIGEgbWF0dGVyIG9mIGltcGxlbWVudGF0aW9uIHdoZXRoZXIgdGhlIHJlY2VpdmVy
IGFjY2VwdHMgYW4gb2ZmZXIgKG5vdGUgd2VsbCwgdGhlIHJlY2VpdmVyKSwgYW5kIGF0dGVtcHRz
IHRvIGRlY29kZSBhIHN0cmVhbSBvbiBhICJiZXN0IGVmZm9ydCIgYmFzaXMsIGtlZXBpbmcgaW4g
bWluZCB0aGF0IHRoZSBzdHJlYW0gaXRzZWxmIGluY2x1ZGVzIGFkZGl0aW9uYWwgbWVhbnMgdG8g
aWRlbnRpZnkgcmVxdWlyZWQgY2FwYWJpbGl0aWVzIG5lY2Vzc2FyeSBmb3IgYSBzdWNjZXNzZnVs
IGRlY29kZS4NCj4NCj4gSWYgdGhhdCBpcyBub3QgYW4gb3B0aW9uLCB3ZSB3b3VsZC9jb3VsZCBu
ZWVkIG1lYW5zIHRvIGlkZW50aWZ5IHRoZSANCj4gdHlwZSBvZiBwYXJhbWV0ZXJzIGluIGEgZm9y
ZXdhcmQgY29tcGF0aWJsZSB3YXkuIEkuZS4sIGNvbnZlbnRpb25zIGJ5IHdoaWNoIHdlIHdvdWxk
IGlkZW50aWZ5IGluIHRoZSBmdXR1cmUgcGFyYW1ldGVycyBhIHJlY2VpdmVyIGNhbiBzYWZlbHkg
aWdub3JlIGFuZCBhdHRlbXB0IHRvIGRlY29kZSwgYW5kIHBhcmFtZXRlcnMgYSByZWNlaXZlciBj
YW5ub3Qgc2FmZWx5IGlnbm9yZS4NCg0KSSB0aGluayBpdCBpcyBmaW5lIHRvIHNheSB0aGF0IHVu
cmVjb2duaXplZCBwYXJhbWV0ZXJzIHNoYWxsIGJlIGlnbm9yZWQuIEl0IGlzIHRoZW4gdXAgdG8g
ZnV0dXJlIHNwZWNpZmljYXRpb25zIHRvIHdvcnJ5IGFib3V0IGJhY2t3YXJkIGNvbXBhdGliaWxp
dHksIHJhdGhlciB0aGFuIHRoaXMgc3BlY2lmaWNhdGlvbiB3b3JyeWluZyBhYm91dCBmb3J3YXJk
IGNvbXBhdGliaWxpdHkuDQoNCj4+IEFsc28sIHRoZSB0ZXh0IGRvZXMgbm90IHNheSB3aGF0IHJl
c3RyaWN0aW9ucyAoaWYgYW55KSB0aGVyZSBhcmUgd2hlbiANCj4+IGl0IGNvbWVzIHRvIG1vZGlm
eSB0aGUgc3RyZWFtIGR1cmluZyBhIHNlc3Npb24uIElzIGl0IGFsbG93ZWQgdG8gDQo+PiBtb2Rp
ZnkgYW55L2FsbCBjaGFyYWN0ZXJpc3RpY3M/DQo+DQo+IE15IHVuZGVyc3RhbmRpbmcgaXMgdGhh
dCB5b3UgY2Fubm90IG1vZGlmeSBjaGFyYWN0ZXJpc3RpY3MgZHVyaW5nIGEgDQo+IHNlc3Npb24u
IElmIHlvdSBuZWVkIHRvIG1vZGlmeSwgeW91IG5lZWQgdG8gc2V0dXAgYSBuZXcgc2Vzc2lvbiBh
bmQgDQo+IGNhbmNlbCB0aGUgY3VycmVudCBvbmUuIEZvciBKUEVHIFhTIHN0cmVhbSBkZWNvZGVy
cywgb25lIGNhbm5vdCBleHBlY3QgdGhhdCBhbiBpbnN0YW5jaWF0ZWQgZGVjb2RlciBjYW4gZGVj
b2RlIGZyb20gbW9kaWZpZWQgcGFyYW1ldGVycyBpbiBtaWQtc3RyZWFtIGxldmVsLiBUaGF0IGlz
LCBpZiB5b3Ugc3RhcnQgZGVjb2RpbmcgaW4gZnVsbC1IRCwgYW5kIHRoZW4gc3RyZWFtIHBhcmFt
ZXRlcnMgYmVjb21lIDhLLCB0aGUgZGVjb2RlciB3aWxsIGhhdmUgdG8gYWJvcnQuDQoNClRoZXNl
IGtpbmQgb2YgdGhpbmdzIG5lZWQgdG8gYmUgc3BlY2lmaWVkLiBJIGRvbid0IHRoaW5rIGl0IG5l
ZWRzIHRvIGJlIGZvcmJpZGRlbiB0byB0cnkgdG8gbW9kaWZ5IHNvbWV0aGluZywgYmVjYXVzZSB0
aGVyZSBjb3VsZCBiZSB0ZXh0IHRoYXQgc3Ryb25nbHkgcmVjb21tZW5kcyBhZ2FpbnN0IGRvaW5n
IGl0Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRl
bmFuY2UNCmF2dEBpZXRmLm9yZw0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy
L3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19hdnQmZD1Ed0lD
QWcmYz1ldUdac3RjYVREbGx2aW1FTjhiN2pYcndxT2YtdjVBX0NkcGduVmZpaU1NJnI9TFR4VUd1
a0xDRWZFVWRvX2JxMDQ4USZtPUx0ZWZRaUxoZHJYd1V5Y2FoN1ptc2F5a19kdEhGLWhNRUJ3SG82
RHBldDAmcz0xdlpUdUZqSS1RYmV4UDVvWDlwZ2EzNWRaWnp0aFhHZ243UzhaZ29kOUxFJmU9DQoN
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBdWRpby9W
aWRlbyBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KYXZ0QGlldGYub3JnDQpodHRwczovL3Vy
bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19t
YWlsbWFuX2xpc3RpbmZvX2F2dCZkPUR3SUNBZyZjPWV1R1pzdGNhVERsbHZpbUVOOGI3alhyd3FP
Zi12NUFfQ2RwZ25WZmlpTU0mcj1MVHhVR3VrTENFZkVVZG9fYnEwNDhRJm09THRlZlFpTGhkclh3
VXljYWg3Wm1zYXlrX2R0SEYtaE1FQndIbzZEcGV0MCZzPTF2WlR1RmpJLVFiZXhQNW9YOXBnYTM1
ZFpaenRoWEdnbjdTOFpnb2Q5TEUmZT0NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQpBdWRpby9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZQ0K
YXZ0QGlldGYub3JnDQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9
aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2F2dCZkPUR3SUdhUSZjPWV1
R1pzdGNhVERsbHZpbUVOOGI3alhyd3FPZi12NUFfQ2RwZ25WZmlpTU0mcj1MVHhVR3VrTENFZkVV
ZG9fYnEwNDhRJm09VnZzYTd1RkE1ejBEV25CU29ORW52YV80aWo1cmJjUUdPd0xwX2ktM3o3dyZz
PW9pTDJwZGw3aF82TFZZLTRFODhoVlZJMU5vRFdzNmpCT0xiMXJXckFfbkkmZT0NCg==



From nobody Mon May 31 12:56:30 2021
Return-Path: 
X-Original-To: avt@ietf.org
Delivered-To: avt@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 271973A2476; Mon, 31 May 2021 12:56:28 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: internet-drafts@ietf.org
To: 
Cc: avt@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.30.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: avt@ietf.org
Message-ID: <162249098808.13074.10462532686162127505@ietfa.amsl.com>
Date: Mon, 31 May 2021 12:56:28 -0700
Archived-At: 
Subject: [AVTCORE] I-D Action: draft-ietf-payload-rtp-jpegxs-15.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 May 2021 19:56:29 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Core Maintenance WG of the IETF.

        Title           : RTP Payload Format for ISO/IEC 21122 (JPEG XS)
        Authors         : Sébastien Lugan
                          Antonin Descampe
                          Corentin Damman
                          Thomas Richter
                          Tim Bruylants
	Filename        : draft-ietf-payload-rtp-jpegxs-15.txt
	Pages           : 31
	Date            : 2021-05-31

Abstract:
   This document specifies a Real-Time Transport Protocol (RTP) payload
   format to be used for transporting JPEG XS (ISO/IEC 21122) encoded
   video.  JPEG XS is a low-latency, lightweight image coding system.
   Compared to an uncompressed video use case, it allows higher
   resolutions and frame rates, while offering visually lossless
   quality, reduced power consumption, and end-to-end latency confined
   to a fraction of a frame.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-jpegxs/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-payload-rtp-jpegxs-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-jpegxs-15


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/