From nobody Wed Aug 4 16:16:56 2021 Return-Path: X-Original-To: sframe@ietfa.amsl.com Delivered-To: sframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71E03A1178 for ; Wed, 4 Aug 2021 16:16:54 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=lowentropy.net header.b=IcexWMZq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ps6ajnJt 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 0p8J4heZ4abd for ; Wed, 4 Aug 2021 16:16:50 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 019B63A1179 for ; Wed, 4 Aug 2021 16:16:49 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 786725C0113; Wed, 4 Aug 2021 19:16:48 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Wed, 04 Aug 2021 19:16:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=LDbTL8HYvtuDmlqJYicUOW24bRb8 ZaqhyIEunaWAZWs=; b=IcexWMZq6wkCXU886cpF7dg0t3/xHJRvy3ktOLJXMLWg HkIzgtZD5nhAHIZ+fTdwPV4CUeSUKVhS3So8gIHpVcLSos/btzphEtyHpgypz95g GTkUFTC0IWzNrQwfTkeaR4JfTr7yPX1peAsphNfm4K1gEfYU+sV92D2h0wkGkhrE WxS8BvVbVgvryyOeP/I66EzVMWrAyP2/xLdw6/EgeV7NXpk+R1zZTD5hxt2dj86b rqeRMW5l+o74zPl2pkRkJ/428HVvgxrWEFcl74tF67Tc40DDpF2jo6FN0kzhm5rz PksKz5DkLwgKnK80CAw0e+rjT4ZmekC//ZKa9tt5aA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=LDbTL8 HYvtuDmlqJYicUOW24bRb8ZaqhyIEunaWAZWs=; b=ps6ajnJtyGpdTazH+K5wOT 7rL6Sajz53Mu3xw1Ld8DvZrYw/NgNUoOVNpVEVEnKbqCbAkXnyScSxsNQmr6K7pz rO3wwyMtxrmprZasE7pkYiqfYXsdp5FIQtshdf76vKOfGLmtUFRDsz2lxMNGqN56 58NeKWYJ3U/IWkCMnKmPuDqMuSfSSg6TGaDfSg7ltHWVEdALQlrfb+KukgcKd2M+ VxeMylQfsbqIwvthvaqcH+RDHSMa4ynkRmCdm/SVIfItaTIz8Jl0bIHJoeR6ely9 3eXiC69MoWJdyOcGM/UeVmhpaV8RNueEUITKDX39Ji5qtj/ZiRj1JMb0vH4Gnc1g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrieekgddujecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepveefiedtleehuedtledtff ejhfefgfeilefhteefudduvddtgeffuefgieefudefnecuffhomhgrihhnpeguohhoughl vgdrtghomhdpihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 167CC3C0449; Wed, 4 Aug 2021 19:16:48 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-548-g3a0b1fef7b-fm-20210802.001-g3a0b1fef Mime-Version: 1.0 Message-Id: <9afa8f7c-e411-4a27-9fe5-8ff2fad25ed3@www.fastmail.com> In-Reply-To: References: Date: Thu, 05 Aug 2021 09:16:20 +1000 From: "Martin Thomson" To: sframe@ietf.org Cc: Bobo Content-Type: text/plain Archived-At: Subject: Re: [Sframe] SFrame Interim X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2021 23:16:55 -0000 Thanks to everyone who contributed. We'll have a two hour meeting 2021-09-02 at 19:00 UTC. That's 5am Friday Australia Eastern and Thursday most other places: 9pm in Europe; 8pm in the UK; 3pm US Eastern; 12pm US Western. As noted below, we'll need updated drafts and discussion on the core issues before we meet if this time is going to be effective. On Fri, Jul 23, 2021, at 11:53, Martin Thomson wrote: > Hi everyone, and welcome back, > > This group has been fairly quiet in the last few months. That doesn't > mean that things haven't happened. The chairs have been in touch with > a few people are there is definitely still interest in doing the work. > > We're going to propose holding an interim meeting in around 6 weeks. > We'd like to gather information on availability, so please fill out the > following poll: > > https://doodle.com/poll/zqxudn46rr2pu33g > > The purpose of the interim meeting will be to answer two questions: > > 1. How do we decide what to protect? > > Right now we have > https://www.ietf.org/archive/id/draft-murillo-avtcore-multi-codec-payload-format-01.html in terms of formal proposals. We will be seeking input on that idea and alternative proposals. The goal here is to understand what use cases the design needs to support and to try to agree on the general shape of a solution. > > 2. What do we protect? > > The design in > https://datatracker.ietf.org/doc/html/draft-omara-sframe-01 proposes > that protection be applied to entire encoded frames, but we have heard > that some people would prefer a different approach. Again, we would > like to understand this problem better. > > If we are going to have an effective meeting, we will need to be > prepared. Please contribute to discussion of these issues ahead of the > meeting. Substantive contributions in the form of internet-drafts are > the best; we'll be requesting that people submit drafts 2 weeks ahead > of the meeting so that those drafts can be discussed. > > We'll be setting an agenda closer to time informed by list discussion. > > Regards, > Martin (for the chairs) > > From nobody Thu Aug 5 14:38:47 2021 Return-Path: X-Original-To: sframe@ietf.org Delivered-To: sframe@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C95183A0CC6; Thu, 5 Aug 2021 14:38:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: sframe@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162819951476.26255.1215294932559599385@ietfa.amsl.com> Date: Thu, 05 Aug 2021 14:38:34 -0700 Archived-At: Subject: [Sframe] Secure Media Frames (sframe) WG Virtual Meeting: 2021-09-02 X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 21:38:43 -0000 The Secure Media Frames (sframe) WG will hold a virtual interim meeting on 2021-09-02 from 19:00 to 21:00 UTC. Agenda: 1. How do we decide what to protect? Right now we have https://www.ietf.org/archive/id/draft-murillo-avtcore-multi-codec-payload-format-01.html in terms of formal proposals. We will be seeking input on that idea and alternative proposals. The goal here is to understand what use cases the design needs to support and to try to agree on the general shape of a solution. 2. What do we protect? The design in https://datatracker.ietf.org/doc/html/draft-omara-sframe-01 proposes that protection be applied to entire encoded frames, but we have heard that some people would prefer a different approach. Again, we would like to understand this problem better. Information about remote participation: https://meet.google.com/ece-ppaa-odd From nobody Fri Aug 27 21:40:34 2021 Return-Path: X-Original-To: sframe@ietfa.amsl.com Delivered-To: sframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947CF3A05DE for ; Fri, 27 Aug 2021 21:40:32 -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 Lvc9iQFBYuEs for ; Fri, 27 Aug 2021 21:40:30 -0700 (PDT) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 1CAA83A05F0 for ; Fri, 27 Aug 2021 21:40:30 -0700 (PDT) Received: by mail-ua1-x933.google.com with SMTP id x23so4633129uav.3 for ; Fri, 27 Aug 2021 21:40:30 -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=tj/1OLiGfaPgL3T+1ZsP8gqMUdcQXsXjA7V4YqBNC7E=; b=NMIn51zZeEqgGvVRVudvphMkFaPvXdsJkIuXQ+0PjkWgWlvI8DrezwXeLbe5HtmPTv Tdxxs6u3Tpv7KuvvZgryMyNhBgzrKsbOlrCSGcZiobBZ2aCMgXpzbA7BHsfqTqkfvJRi 0zm2JwZequuTJgJ7pGQgwyaPrH+GeHu014aXk71c7/lYFGcw4V7UEl2lfzjPfYPpkB06 k6Ym62KwPl/7pVYi7CxsjsUp8QInBqtlgeKndQHmjuGIjDJcrRlsV520TGuaHwDXAwoz xWhSO2fQamW+dq6kSdL0M3pz+QCNaWUK8l7RgXmHfxZwZzEEiiIhKX8L0975ZMT0Kwq6 +F0g== 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=tj/1OLiGfaPgL3T+1ZsP8gqMUdcQXsXjA7V4YqBNC7E=; b=CuIX1ATRj11IvCSnvYqoxgVC/V9REgdlzugFAumRBWXsknCPfeMpSUP4lhAIdtAsqA 3rE7s/r72TkzyQ3+Urfjb2B3EIWZJ+euSXPQhMILSv8qymsQpUq9JP9nrta6in7gBUNl I9tCW+eYURcxNh14OnIRNrE0T2/o6slGTp+yzhr0Ny60TlZ6eg5DZANCroaCBl6ulf+D 1nwjmnwhbkTEDRLVQq7VmBSkeENC/MBuQ52s4O9jM7Tuei+AkajqSJZhqfxu6KwiG45N 20uaiK3DBRm2TY1k9z5fJh+CUTbkBdx7g5nkXsm2ed+YgtL0IeN2mMIwchpu4cEx7Tmv KmlQ== X-Gm-Message-State: AOAM533pmcDb0V5noSlWlVeQCvmPahCVv5tCv5p/OL0snDph8xOER3b4 KVu1jkfkO6X7PUpVE9GNd0C1QlnPfi71wZK+t6XTPmuF X-Google-Smtp-Source: ABdhPJx0AZo5yt8NQtsnivvIo3hxwizFpEey4VXTmsGQuSIEGXVxs8Zq//GYPHenphaAad4Rr3OoIe9U3/n4mk1b85w= X-Received: by 2002:ab0:694b:: with SMTP id c11mr9908595uas.87.1630125627681; Fri, 27 Aug 2021 21:40:27 -0700 (PDT) MIME-Version: 1.0 From: "Murray S. Kucherawy" Date: Fri, 27 Aug 2021 21:40:15 -0700 Message-ID: To: sframe@ietf.org Content-Type: multipart/alternative; boundary="000000000000fa324805ca973232" Archived-At: Subject: [Sframe] Status of the SFRAME WG X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2021 04:40:33 -0000 --000000000000fa324805ca973232 Content-Type: text/plain; charset="UTF-8" Colleagues, I'm concerned with what appears to be rather low energy in this working group. There's been almost no activity on the list since IETF 110, and it looks like there's been little interest shown in an interim meeting despite efforts by the chairs to re-establish momentum. It also looks like some of the work expected to be done in SFRAME is actually happening in AVTCORE. Is there still work to be done here and the energy and interest to do it? Should we propose moving the remaining document to AVTCORE or some other venue? It had a milestone of June 2021, but that's now past without adopting any document to satisfy it. -MSK, ART AD --000000000000fa324805ca973232 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Colleagues,

I'm concerne= d with what appears to be rather low energy in this working group.=C2=A0 Th= ere's been almost no activity on the list since IETF 110, and it looks = like there's been little interest shown in an interim meeting despite e= fforts by the chairs to re-establish momentum.=C2=A0 It also looks like som= e of the work expected to be done in SFRAME is actually happening in AVTCOR= E.

Is there still work to be done here and the ene= rgy and interest to do it?=C2=A0 Should we propose moving the remaining doc= ument to AVTCORE or some other venue?=C2=A0 It had a milestone of June 2021= , but that's now past without adopting any document to satisfy it.

-MSK, ART AD


--000000000000fa324805ca973232-- From nobody Sat Aug 28 10:50:45 2021 Return-Path: X-Original-To: sframe@ietfa.amsl.com Delivered-To: sframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD8D3A11FF for ; Sat, 28 Aug 2021 10:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 f87wPzd-zExY for ; Sat, 28 Aug 2021 10:50:38 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 CAA1B3A11FE for ; Sat, 28 Aug 2021 10:50:37 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id ay33so10839071qkb.10 for ; Sat, 28 Aug 2021 10:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B/sgnJezoxPUqxj17gixqZVca1P7IfKg7VSa9SYfAzQ=; b=P6y/Hed7wIeIiOQ+ALPm+bEEGkgLrbBwVumc7+JAxDxF1ga+CnmMPfcca/hr90jJre 9ZER1BLSUTKMoNicpSMOyRAYWLx+ATT+7RQjfo3hhbXoOIOSo6Ucu2DilgSiRDsMhcNM /1JYIlD1L3uLt4ZmYdpr90gBlDGt/j6OfbfCiOQZf3u+0YF3DS5of/oA7W8QZKrU1i0s izZUqrpAaEDcpLzMv56L0+tUk0Ed4U/XQ/VbhRyy7DJazy5KxSVEJ0jYKqX0i949vxAm 9Y4wDPtLY60i+cMU4I7yKhT62w/FUwFgAceHjp/3GJ3ZAA4EfGeDU3MWvlouM7UFtGHg sDbA== 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=B/sgnJezoxPUqxj17gixqZVca1P7IfKg7VSa9SYfAzQ=; b=U2xDdoyA+Q5Mvn7riqv8xtUDRm94H4d6n1rmeX4Iod1Qwg/0z1XisMRIdL2RuBgFG4 Y1DcaVCKQ3kVWzQeBKCXjulsG8YMOsRoNsrWg8PtTtUhcZnQVqkIWksIAJ8b6oCnX5Dm c76gj0DtvP1DvlB6j01p4SjVOrQACqp7gkCn0pgcPQMFxZfF9dGrHOdF4l09ZeoyvXy7 kkOemZX4gaS5QOmQpD5LFcxmDo18bAgN6O8PPdUC8NWu0823sUbKNE7RMaHC+Y3paLHT QTrCuja1+u8AoPI94DQ880jndnC4ghMSdRbE9N6wKNAmah7TgvvNBB6uPYn9xw0TzbKT 8RQg== X-Gm-Message-State: AOAM531sl5d7/tNltSfk4S+iIStx/gAArQ4YgUoUnO1EyYDOejEuvI6W mXbWB3lzdZnI/LTnarMKmql1J6SQoU0nQ8a1QI9/+aDkRzw= X-Google-Smtp-Source: ABdhPJyLS44azMf28+zEoTMe0CdtcFXpN1ph7AmsEioIojahPtJ04RGU+1RYp9JJAEwbcxzlPxkb4sPI6MHAlIK+83E= X-Received: by 2002:a37:a9d2:: with SMTP id s201mr14142924qke.132.1630173035283; Sat, 28 Aug 2021 10:50:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Sat, 28 Aug 2021 07:50:24 -1000 Message-ID: To: "Murray S. Kucherawy" Cc: sframe@ietf.org Content-Type: multipart/alternative; boundary="000000000000b0d4f605caa23c99" Archived-At: Subject: Re: [Sframe] Status of the SFRAME WG X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2021 17:50:44 -0000 --000000000000b0d4f605caa23c99 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Murray, Thanks for checking in. To be clear, work is still happening. See the SFrame vs SPacket discussion at AVTCORE at IETF 111. There have been some discussions among a few of us following on that, sporadically because of summer holidays. I=E2=80=99ll try to gather up some notes from that and st= art some conversations on the mailing list. My read on the state of things is: 1. We should probably go ahead and adopt draft-omara-sframe and draft-barnes-sframe-mls. There is shipping code using both of them, and pretty broad agreement on the contents. In fact, I don=E2=80=99t expect a = ton of changes needed before WGLC; but of course, other folks in the WG should have their say. 2. We need to figure out what the story is with regard to carrying SFrame in RTP and signaling it in SDP. Sergio made a proposal in AVTCORE; I have some different ideas that I need to write up for the group. We should probably have a virtual interim to get aligned on a path. 3. As background for that discussion, folks should be aware that the W3C WebRTC WG is considering taking up work that would leverage the RTP/SDP work, so there is a consumer lined up to add some shipping pressure. https://lists.w3.org/Archives/Public/public-webrtc/2021Aug/0038.html End of brain dump. Interested if others have a different read. Cheers, =E2=80=94Richard On Fri, Aug 27, 2021 at 18:40 Murray S. Kucherawy wrote: > Colleagues, > > I'm concerned with what appears to be rather low energy in this working > group. There's been almost no activity on the list since IETF 110, and i= t > looks like there's been little interest shown in an interim meeting despi= te > efforts by the chairs to re-establish momentum. It also looks like some = of > the work expected to be done in SFRAME is actually happening in AVTCORE. > > Is there still work to be done here and the energy and interest to do it? > Should we propose moving the remaining document to AVTCORE or some other > venue? It had a milestone of June 2021, but that's now past without > adopting any document to satisfy it. > > -MSK, ART AD > > > > -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --000000000000b0d4f605caa23c99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Murray,

Thanks for checking in.=C2=A0 To be clear, work is still happening.=C2= =A0 See the SFrame vs SPacket discussion at AVTCORE at IETF 111.=C2=A0 Ther= e have been some discussions among a few of us following on that, sporadica= lly because of summer holidays.=C2=A0 I=E2=80=99ll try to gather up some no= tes from that and start some conversations on the mailing=C2=A0list. =C2=A0=

My read on the state of= things is:

1. We should= probably go ahead and adopt draft-omara-sframe and draft-barnes-sframe-mls= . =C2=A0 There is shipping code using both of them, and pretty broad agreem= ent on the contents.=C2=A0 In fact, I don=E2=80=99t expect a ton of changes= needed before WGLC; but of course, other folks in the WG should have their= say.=C2=A0

2. We need t= o figure out what the story is with regard to carrying SFrame in RTP and si= gnaling it in SDP.=C2=A0 Sergio made a proposal in AVTCORE; I have some dif= ferent ideas that I need to write up for the group.=C2=A0 We should probabl= y have a virtual interim to get aligned on a path.=C2=A0

3. As background for that discussion, folk= s should be aware that the W3C WebRTC WG is considering taking up work that= would leverage the RTP/SDP work, so there is a consumer lined up to add so= me shipping pressure.=C2=A0

End of brain dump.=C2=A0 Inte= rested if others have a different read.

Cheers,
=E2=80=94Richard



On Fri, Aug 27, 2021 at 18= :40 Murray S. Kucherawy <superuse= r@gmail.com> wrote:
= Colleagues,

I'm concerned with what appears to= be rather low energy in this working group.=C2=A0 There's been almost = no activity on the list since IETF 110, and it looks like there's been = little interest shown in an interim meeting despite efforts by the chairs t= o re-establish momentum.=C2=A0 It also looks like some of the work expected= to be done in SFRAME is actually happening in AVTCORE.

Is there still work to be done here and the energy and interest to do= it?=C2=A0 Should we propose moving the remaining document to AVTCORE or so= me other venue?=C2=A0 It had a milestone of June 2021, but that's now p= ast without adopting any document to satisfy it.

-= MSK, ART AD


=
--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--000000000000b0d4f605caa23c99-- From nobody Sat Aug 28 10:53:36 2021 Return-Path: X-Original-To: sframe@ietfa.amsl.com Delivered-To: sframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D64D3A1219 for ; Sat, 28 Aug 2021 10:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 vhBFRD10zKtn for ; Sat, 28 Aug 2021 10:53:28 -0700 (PDT) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 B58873A121D for ; Sat, 28 Aug 2021 10:53:28 -0700 (PDT) Received: by mail-qv1-xf2b.google.com with SMTP id dt3so5968140qvb.6 for ; Sat, 28 Aug 2021 10:53:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SUFNbdhQnp5WaND8a+ng1jbDu5fBQWAhgtd19CEal8g=; b=mNXup/DJkDNV5PQ2BS+gQdy3ItrtQJLmNLJKPwfDAd7FDfHgOqPbmolZhuD4WIbyNR RWTONNYDxk31bWIAl/a2DFFiYsn2VWsxHncL/Y4y6TI1okmc0LNNQfCUzeMWrqK6akSM EpdjMIivAV4YKn93v1gVbdE0dJAS9vFQTyoSF9cK81iqvTEnItORcbgx+Pp7j7V/ZUfr oc5nmKcnl8n36X5qlJja7tCs+QvHpOpgpErReCni0fiE649gO5R6wDIZXpc/uJM7q7O9 yN9K5yUqlWircDDE241L4bG3S4i8zMw2hHriQjy1+M+8WT1tL4gtqxWwbu6KIb326+mL XaNA== 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=SUFNbdhQnp5WaND8a+ng1jbDu5fBQWAhgtd19CEal8g=; b=DAFOQi7YA/wDTU5zmUdAGjTKIi6zeUak22aiiGnlKcde/HewQVy+d0SeHUlVs4ta6c XTGFUO1Yuzt9WOcqhntuEK6Puw6RKR01H+PFxkzKiCugT3A+0W1aoWCB6l8o/A419odg dvht51LECpRQlRgPM4PTUORO1zOjFR6f+19k25NDy47h11YpnNNcPk/b5Ocsthub6Rxs 15MzG7f3WN6aAcY30ywtH5Gp270zwrr+8s8a2wMI3RlaHhkUwtSpWP+N8gp80Mt3hAna izBjHHA6NFUqPSn5vTdrqvm+En3/FDxFJfpIwI+6JHA3nMtNVWOdLsULpjInBMCT7iSB L5XA== X-Gm-Message-State: AOAM530NTCfqP8Z+zN+e0j6cyiAoPqSG6XAKpaxRUlwIbEF8XtnSL35J ZWGFxKy0uwUiUG9ghRHrxnJYAP50gBDvyzS1BjHQCg== X-Google-Smtp-Source: ABdhPJwYU7nY8qNRoXLNMJirSaKrJyx8kbqTAhnihROmIckBshtZwfMGPUJzSzrdxNTKhvht89POs9/3qJA8FAiGizs= X-Received: by 2002:ad4:442c:: with SMTP id e12mr15651704qvt.36.1630173206255; Sat, 28 Aug 2021 10:53:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Sat, 28 Aug 2021 07:53:15 -1000 Message-ID: To: "Murray S. Kucherawy" Cc: sframe@ietf.org Content-Type: multipart/alternative; boundary="000000000000e1a98505caa246ab" Archived-At: Subject: Re: [Sframe] Status of the SFRAME WG X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2021 17:53:35 -0000 --000000000000e1a98505caa246ab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry, just realized I blew past the AVTCORE question. This group does have work to do, in terms of setting the base encapsulation format and keying (draft-omara and draft-barnes). The details of the RTP/SDP stuff might be worked out in AVTCORE, but I think that will work best if this group aligns on a starting point first. =E2=80=94RLB On Sat, Aug 28, 2021 at 07:50 Richard Barnes wrote: > Hi Murray, > > Thanks for checking in. To be clear, work is still happening. See the > SFrame vs SPacket discussion at AVTCORE at IETF 111. There have been som= e > discussions among a few of us following on that, sporadically because of > summer holidays. I=E2=80=99ll try to gather up some notes from that and = start some > conversations on the mailing list. > > My read on the state of things is: > > 1. We should probably go ahead and adopt draft-omara-sframe and > draft-barnes-sframe-mls. There is shipping code using both of them, and > pretty broad agreement on the contents. In fact, I don=E2=80=99t expect = a ton of > changes needed before WGLC; but of course, other folks in the WG should > have their say. > > 2. We need to figure out what the story is with regard to carrying SFrame > in RTP and signaling it in SDP. Sergio made a proposal in AVTCORE; I hav= e > some different ideas that I need to write up for the group. We should > probably have a virtual interim to get aligned on a path. > > 3. As background for that discussion, folks should be aware that the W3C > WebRTC WG is considering taking up work that would leverage the RTP/SDP > work, so there is a consumer lined up to add some shipping pressure. > > https://lists.w3.org/Archives/Public/public-webrtc/2021Aug/0038.html > > End of brain dump. Interested if others have a different read. > > Cheers, > =E2=80=94Richard > > > > On Fri, Aug 27, 2021 at 18:40 Murray S. Kucherawy > wrote: > >> Colleagues, >> >> I'm concerned with what appears to be rather low energy in this working >> group. There's been almost no activity on the list since IETF 110, and = it >> looks like there's been little interest shown in an interim meeting desp= ite >> efforts by the chairs to re-establish momentum. It also looks like some= of >> the work expected to be done in SFRAME is actually happening in AVTCORE. >> >> Is there still work to be done here and the energy and interest to do >> it? Should we propose moving the remaining document to AVTCORE or some >> other venue? It had a milestone of June 2021, but that's now past witho= ut >> adopting any document to satisfy it. >> >> -MSK, ART AD >> >> >> >> -- >> Sframe mailing list >> Sframe@ietf.org >> https://www.ietf.org/mailman/listinfo/sframe >> > --000000000000e1a98505caa246ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry, just realized I blew past the AVTCORE question. = =C2=A0

This group does h= ave work to do, in terms of setting the base encapsulation format and keyin= g (draft-omara and draft-barnes).

The details of the RTP/SDP stuff might be worked out in AVTCORE, = but I think that will work best if this group aligns on a starting point fi= rst.=C2=A0

=E2=80=94RLB<= /div>

On Sat, Aug 28, 2021 at 07:50 Richard Barnes <rlb@ipv.sx> wrote:
Hi Murray,

Thanks for= checking in.=C2=A0 To be clear, work is still happening.=C2=A0 See the SFr= ame vs SPacket discussion at AVTCORE at IETF 111.=C2=A0 There have been som= e discussions among a few of us following on that, sporadically because of = summer holidays.=C2=A0 I=E2=80=99ll try to gather up some notes from that a= nd start some conversations on the mailing=C2=A0list. =C2=A0

My read on the state of things is:

1. We should probably go a= head and adopt draft-omara-sframe and draft-barnes-sframe-mls. =C2=A0 There= is shipping code using both of them, and pretty broad agreement on the con= tents.=C2=A0 In fact, I don=E2=80=99t expect a ton of changes needed before= WGLC; but of course, other folks in the WG should have their say.=C2=A0

2. We need to figure out w= hat the story is with regard to carrying SFrame in RTP and signaling it in = SDP.=C2=A0 Sergio made a proposal in AVTCORE; I have some different ideas t= hat I need to write up for the group.=C2=A0 We should probably have a virtu= al interim to get aligned on a path.=C2=A0

3. As background for that discussion, folks should be aw= are that the W3C WebRTC WG is considering taking up work that would leverag= e the RTP/SDP work, so there is a consumer lined up to add some shipping pr= essure.=C2=A0

End of brain dump.=C2=A0 = Interested if others have a different read.

Cheers,
=E2=80=94Richard



On Fri, Aug 27, 2021= at 18:40 Murray S. Kucherawy <superuser@gmail.com> wrote:
Colleagues,

I'm concer= ned with what appears to be rather low energy in this working group.=C2=A0 = There's been almost no activity on the list since IETF 110, and it look= s like there's been little interest shown in an interim meeting despite= efforts by the chairs to re-establish momentum.=C2=A0 It also looks like s= ome of the work expected to be done in SFRAME is actually happening in AVTC= ORE.

Is there still work to be done here and the e= nergy and interest to do it?=C2=A0 Should we propose moving the remaining d= ocument to AVTCORE or some other venue?=C2=A0 It had a milestone of June 20= 21, but that's now past without adopting any document to satisfy it.

-MSK, ART AD
--000000000000e1a98505caa246ab-- From nobody Sat Aug 28 11:24:22 2021 Return-Path: X-Original-To: sframe@ietfa.amsl.com Delivered-To: sframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1A63A139B for ; Sat, 28 Aug 2021 11:24: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, 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 AWUmlXIHcHZ2 for ; Sat, 28 Aug 2021 11:24:15 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 1312A3A1348 for ; Sat, 28 Aug 2021 11:24:15 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id g13so21664677lfj.12 for ; Sat, 28 Aug 2021 11:24:14 -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=t8fKuSys2s/X/jiBZv1uJstuMPFi2Mr9HrqnGw0AHx4=; b=C9hAdJGWATJpvLGlJ8k1s5vrN0R8r6T/5I5iwQg4ARe7QEQhzFEGWcpYJd8rNTubN0 sCbAl1guiuHpacM7J1OcPup+r0XuQNeOQrVSeKRZNI+H0ujz7p6lUuaJHn/95JePUd8D Qf5UvCzxwHl7p7lJxxdTHkd0d7/fV50rbcbEBLSO+1vxwiiMdsbz4qXazaiPAfuoFYlT fbujXw6EW2XO70yJq8B+0ZKwc+zsBJxwbvi6u7HK8uaU4nU4XWZCZ16scQU8WeXmVEBa xmBJAiHqgfNPelV42g83fLJfkKQmfmJQ0BCobSZEvfJ6A7ASf3sxUbO5EOY+EukrVi8E FxBQ== 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=t8fKuSys2s/X/jiBZv1uJstuMPFi2Mr9HrqnGw0AHx4=; b=IJ0+/8BNlazM3J3CEL7KPaqvcYiUK2nz/vNWm9lnM/Si/OvJkiv+BgeEF5z3NzL8N0 3veAnbwXDLm+GURXMMXad/RlmGOuHWTnyCLW3DOWXcjE0wHSzvf8upysCP4hcH30oriQ dhPP9ItVAKNmTJIzYAdSfaPnfjXzadMSm5KgEAPn5Xpu+X8M0Pad1zUzLXd0TKsq7Zpv 570wWpamujtcXUYVXTk4tSOfTQsmMsBEkccwtMUe8pTxMY7kUJo2V37IT6xd+MEFnznM MAaJ9yUROeNFte7HrtpE2l5CKp2me9nIO3FBpPEZmLvIeGcCio5OdN0bAvrRr+6EGCbF fHAw== X-Gm-Message-State: AOAM533h9WExVNqirkYKVn7mN4STMoSXdVzj34uvTmnEbeKJg7HLXFhq SMaZCSxFdfEV151xGoEVeVtUBZh1D4X0ZAHcWOs= X-Google-Smtp-Source: ABdhPJy5hac8S8tHDdVZYPJw+d370NV8gGu+AXoevkD6vn1b3ch16todR1dWnJP5oMrL3S6Q73uFqjo6H6CiYBjHqoU= X-Received: by 2002:a19:4958:: with SMTP id l24mr10805209lfj.48.1630175051585; Sat, 28 Aug 2021 11:24:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bernard Aboba Date: Sat, 28 Aug 2021 11:24:00 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: sframe@ietf.org Content-Type: multipart/alternative; boundary="000000000000df1ece05caa2b410" Archived-At: Subject: Re: [Sframe] Status of the SFRAME WG X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2021 18:24:20 -0000 --000000000000df1ece05caa2b410 Content-Type: text/plain; charset="UTF-8" Murray -- Standards work often slows down in August as people take vacation. So it is not surprising to experience difficulty in getting a WG meeting together in early September. In the past I've had to cancel WG interims scheduled in August or early September, and just last week we had to extend a WGLC due to lack of responses. So some of what you are seeing may be the general slowdown in August. Aside from that though, I do think there is reason to take another look at the problem definition in SFRAME WG. During the pandemic the disparate worlds of streaming and realtime communications have begun to merge, with the new category of "low latency streaming" emerging. We've seen developers taking a fresh look at problems such as video ingestion (e.g. RUSH, WISH) and low latency streaming (e.g. media over QUIC or WebRTC data channel). In the new architectures that are emerging, some of the traditional streaming architectural elements are being rethought. As one example, protocols such as WISH enable endpoints to upload simulcast or scalable video coding, rather than requiring a transcoding service. Also, APIs such as WebCodecs make it possible to decode and render video without containerization (as had been required when using MSE API). As these new ideas take shape in newly chartered WGs or BOFs, it may be appropriate to consider whether the SFRAME WG is targeting the right problems. Traditionally, streaming architectures have focused on the generalized transport of frames whereas RTP has forsaken generic encapsulations, choosing instead to customize packetization to each codec. As a result, at the IETF 111 AVTCORE meeting, Sergio presented SPacket, which while having quite a bit in common with SFrame, has security services occurring after packetization rather than before. However, even if SFrame turns out not to be suitable for use with RTP, it still may prove useful in the new architectures. As an example, in a low latency streaming use case requiring support for content protection (e.g. sports, concerts, etc.) it may be desirable for the downstream leg to bypass traditional content protection schemes based on containerization, just as next generation ingestion protocols may make it possible to bypass transcoding services. Could SFRAME play a role here? It may be worth considering. On Fri, Aug 27, 2021 at 9:40 PM Murray S. Kucherawy wrote: > Colleagues, > > I'm concerned with what appears to be rather low energy in this working > group. There's been almost no activity on the list since IETF 110, and it > looks like there's been little interest shown in an interim meeting despite > efforts by the chairs to re-establish momentum. It also looks like some of > the work expected to be done in SFRAME is actually happening in AVTCORE. > > Is there still work to be done here and the energy and interest to do it? > Should we propose moving the remaining document to AVTCORE or some other > venue? It had a milestone of June 2021, but that's now past without > adopting any document to satisfy it. > > -MSK, ART AD > > > -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --000000000000df1ece05caa2b410 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Murray --

Standards work often slows do= wn in August as people take vacation. So it is not surprising to experience= difficulty in getting a WG meeting together in early September.=C2=A0 In t= he past I've had to cancel WG interims scheduled in August or early Sep= tember, and just last week we had to extend a WGLC due to lack of responses= . So some of what you are seeing may=C2=A0be the general slowdown in August= .=C2=A0

Aside from that though, I do think there i= s reason to take another look at the problem definition in SFRAME WG.=C2=A0= During the pandemic the disparate worlds of streaming and realtime=C2=A0co= mmunications have begun to merge, with the new category of "low latenc= y streaming" emerging. We've seen developers taking a fresh look a= t problems such as video ingestion (e.g. RUSH, WISH) and low latency stream= ing (e.g. media over QUIC or WebRTC data channel).=C2=A0 In the new archite= ctures that are emerging, some of the traditional streaming architectural= =C2=A0elements are being rethought. As one example, protocols such as WISH = enable endpoints to upload simulcast or scalable video coding, rather than = requiring a transcoding service.=C2=A0 Also, APIs such as WebCodecs make it= possible to decode and render video without containerization (as had been = required when using MSE API).=C2=A0

As these new i= deas take shape in newly chartered WGs or BOFs, it may be appropriate to co= nsider whether the SFRAME WG is targeting the right problems.=C2=A0 Traditi= onally, streaming architectures have focused on the generalized transport o= f frames whereas RTP has forsaken generic encapsulations, choosing instead = to customize packetization to each codec.=C2=A0 As a result, at the IETF 11= 1 AVTCORE meeting, Sergio presented SPacket, which while having quite a bit= in common with SFrame, has security services occurring after packetization= rather than before.

However, even if SFrame turns= out not to be suitable for use with RTP, it still may prove useful in the = new architectures.=C2=A0 As an example, in a low latency streaming use case= requiring support for content protection (e.g. sports, concerts, etc.) it = may be desirable for the=C2=A0downstream leg to bypass traditional content = protection schemes based on containerization, just as next generation inges= tion protocols may make it possible to bypass transcoding services.=C2=A0 C= ould SFRAME play a role here? It may be worth considering.

<= div class=3D"gmail_quote">
On Fri, Aug= 27, 2021 at 9:40 PM Murray S. Kucherawy <superuser@gmail.com> wrote:
Colleagues,
I'm concerned with what appears to be rather low energy in = this working group.=C2=A0 There's been almost no activity on the list s= ince IETF 110, and it looks like there's been little interest shown in = an interim meeting despite efforts by the chairs to re-establish momentum.= =C2=A0 It also looks like some of the work expected to be done in SFRAME is= actually happening in AVTCORE.

Is there still wor= k to be done here and the energy and interest to do it?=C2=A0 Should we pro= pose moving the remaining document to AVTCORE or some other venue?=C2=A0 It= had a milestone of June 2021, but that's now past without adopting any= document to satisfy it.

-MSK, ART AD


--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--000000000000df1ece05caa2b410-- From nobody Sat Aug 28 13:47:11 2021 Return-Path: X-Original-To: sframe@ietfa.amsl.com Delivered-To: sframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367323A1DB6 for ; Sat, 28 Aug 2021 13:47:08 -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 KVRhikDbE4fx for ; Sat, 28 Aug 2021 13:47:06 -0700 (PDT) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 8803F3A1DB4 for ; Sat, 28 Aug 2021 13:47:06 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id d6so1047624vsr.7 for ; Sat, 28 Aug 2021 13:47:06 -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=Sg8d9tNVZujwKtvDppEZhm17Y61G2YHTN4xPnw9S5/0=; b=Pm4H7m8RPfvmZcT1f75WYcQoDB1701zXzP4gd0AwlFdpmHucR9mfeToqmbtW4zwF0v tMDAo3XdZhP/D09t/HGvHHf0kV8HDBpalrIFwTom/TIdFj6BpSGFaUmPePiNElFHno86 LukjVipVEYeJ+uyQtb07ih+JM1yKE34/NPBiNi2JpRMxI3gh1qfbuIP3+GIe733lEs+d 86CfITKXOQLn++uBYr+MtqpGHR1o3OhZ/Lir5cXrARFS/CGE7qxKvRNSFmB3GgjBhHcr f4wJwBB7Eqndnrc6Z5ptv76i3EcKyqy0HJSnW0WuMzqnybzl9w1xFWSNLcVGIpRUo++D 4T2A== 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=Sg8d9tNVZujwKtvDppEZhm17Y61G2YHTN4xPnw9S5/0=; b=nyii9NKn0F1yryIHO+rp9bhoKEKVEhfZKH9VhKnojiCTTOFqREABRg5NxOpyJfJIC/ YaZmiuke/comZeBc1/qCPWE9QCw4udiHOQzet2OnHcS9LMPOKCEJZeGhWMsQNSoHu63C bCSDTX801SONrAyc6uT7/QQwCokxaZz4DifC+MfRk2GrNXr7+A5HZppC02l+U1fjHW1C 8ptJ02LBEG9Yr8V1lrzVRcfv7LCDK/rxOXzNOHhhARC8mOxeWJCmL+l25WzEMNkbGWkt FnfBV7Ero5ftrU1jRJXU1Q72E8WVAtWdYoFBixNI9+lOOFNkxC6LDctMiBbZucb9+oiF Qb1w== X-Gm-Message-State: AOAM533NVn4NrbeuBJGwgQiAgfbUSpodF1WQBIgxECQPrO8RDxT8d8YK SeKAp9ybmx1O/N3pFMY/UCsXLGufInodVXhxDhCBlNEV X-Google-Smtp-Source: ABdhPJya/2PKu0TOs2c15gHLraChjqcAou8+ZblpCMdIE5QEEq4rJSCJHpSxk2Owk+WgeyN4g6CHFBP2+kOcSm3ZbyI= X-Received: by 2002:a67:d216:: with SMTP id y22mr6450419vsi.40.1630183623840; Sat, 28 Aug 2021 13:47:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Sat, 28 Aug 2021 13:46:53 -0700 Message-ID: To: Bernard Aboba Cc: sframe@ietf.org Content-Type: multipart/alternative; boundary="000000000000d155b905caa4b3cf" Archived-At: Subject: Re: [Sframe] Status of the SFRAME WG X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2021 20:47:09 -0000 --000000000000d155b905caa4b3cf Content-Type: text/plain; charset="UTF-8" Hi Bernard, On Sat, Aug 28, 2021 at 11:24 AM Bernard Aboba wrote: > Murray -- > > Standards work often slows down in August as people take vacation. So it > is not surprising to experience difficulty in getting a WG meeting together > in early September. In the past I've had to cancel WG interims scheduled > in August or early September, and just last week we had to extend a WGLC > due to lack of responses. So some of what you are seeing may be the general > slowdown in August. > Sure, if I were only talking about August/September. But the last real chatter on the WG list trailed off in March. Aside from that though, I do think there is reason to take another look at > the problem definition in SFRAME WG. During the pandemic the disparate > worlds of streaming and realtime communications have begun to merge, with > the new category of "low latency streaming" emerging. We've seen developers > taking a fresh look at problems such as video ingestion (e.g. RUSH, WISH) > and low latency streaming (e.g. media over QUIC or WebRTC data channel). > In the new architectures that are emerging, some of the traditional > streaming architectural elements are being rethought. As one example, > protocols such as WISH enable endpoints to upload simulcast or scalable > video coding, rather than requiring a transcoding service. Also, APIs such > as WebCodecs make it possible to decode and render video without > containerization (as had been required when using MSE API). > > As these new ideas take shape in newly chartered WGs or BOFs, it may be > appropriate to consider whether the SFRAME WG is targeting the right > problems. Traditionally, streaming architectures have focused on the > generalized transport of frames whereas RTP has forsaken generic > encapsulations, choosing instead to customize packetization to each codec. > As a result, at the IETF 111 AVTCORE meeting, Sergio presented SPacket, > which while having quite a bit in common with SFrame, has security services > occurring after packetization rather than before. > > However, even if SFrame turns out not to be suitable for use with RTP, it > still may prove useful in the new architectures. As an example, in a low > latency streaming use case requiring support for content protection (e.g. > sports, concerts, etc.) it may be desirable for the downstream leg to > bypass traditional content protection schemes based on containerization, > just as next generation ingestion protocols may make it possible to bypass > transcoding services. Could SFRAME play a role here? It may be worth > considering. > If there's a rechartering to be considered to (ahem) frame the working group more appropriately, let's have that discussion. I'm happy to support whatever path will enable meaningful work as the output. But in particular, I'm interested in supporting the chairs to restore the WG's momentum. -MSK --000000000000d155b905caa4b3cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bernard,

<= div dir=3D"ltr" class=3D"gmail_attr">On Sat, Aug 28, 2021 at 11:24 AM Berna= rd Aboba <bernard.aboba@gmail= .com> wrote:
Murray --

Standards work often slow= s down in August as people take vacation. So it is not surprising to experi= ence difficulty in getting a WG meeting together in early September.=C2=A0 = In the past I've had to cancel WG interims scheduled in August or early= September, and just last week we had to extend a WGLC due to lack of respo= nses. So some of what you are seeing may=C2=A0be the general slowdown in Au= gust.=C2=A0

Sure, if I were onl= y talking about August/September.=C2=A0 But the last real chatter on the WG= list trailed off in March.

Aside from that though, I = do think there is reason to take another look at the problem definition in = SFRAME WG.=C2=A0 During the pandemic the disparate worlds of streaming and = realtime=C2=A0communications have begun to merge, with the new category of = "low latency streaming" emerging. We've seen developers takin= g a fresh look at problems such as video ingestion (e.g. RUSH, WISH) and lo= w latency streaming (e.g. media over QUIC or WebRTC data channel).=C2=A0 In= the new architectures that are emerging, some of the traditional streaming= architectural=C2=A0elements are being rethought. As one example, protocols= such as WISH enable endpoints to upload simulcast or scalable video coding= , rather than requiring a transcoding service.=C2=A0 Also, APIs such as Web= Codecs make it possible to decode and render video without containerization= (as had been required when using MSE API).=C2=A0

= As these new ideas take shape in newly chartered WGs or BOFs, it may be app= ropriate to consider whether the SFRAME WG is targeting the right problems.= =C2=A0 Traditionally, streaming architectures have focused on the generaliz= ed transport of frames whereas RTP has forsaken generic encapsulations, cho= osing instead to customize packetization to each codec.=C2=A0 As a result, = at the IETF 111 AVTCORE meeting, Sergio presented SPacket, which while havi= ng quite a bit in common with SFrame, has security services occurring after= packetization rather than before.

However, even i= f SFrame turns out not to be suitable for use with RTP, it still may prove = useful in the new architectures.=C2=A0 As an example, in a low latency stre= aming use case requiring support for content protection (e.g. sports, conce= rts, etc.) it may be desirable for the=C2=A0downstream leg to bypass tradit= ional content protection schemes based on containerization, just as next ge= neration ingestion protocols may make it possible to bypass transcoding ser= vices.=C2=A0 Could SFRAME play a role here? It may be worth considering.

If there's a rechartering to be co= nsidered to (ahem) frame the working group more appropriately, let's ha= ve that discussion.=C2=A0 I'm happy to support whatever path will enabl= e meaningful work as the output.=C2=A0 But in particular, I'm intereste= d in supporting the chairs to restore the WG's momentum.

-MSK
--000000000000d155b905caa4b3cf-- From nobody Sat Aug 28 16:18:34 2021 Return-Path: X-Original-To: sframe@ietfa.amsl.com Delivered-To: sframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB493A2624 for ; Sat, 28 Aug 2021 16:18:32 -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 gdkqpXV1vLvo for ; Sat, 28 Aug 2021 16:18:29 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450: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 4CD3F3A2623 for ; Sat, 28 Aug 2021 16:18:29 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id bq28so22680019lfb.7 for ; Sat, 28 Aug 2021 16:18:29 -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=X4rue7s8VGFo2uJNEo23GfqXBOkg12BAA3jG74oSzB8=; b=KMB+Wr7LYmWNOxD2Z3dRslRPEXC5Xs/ABOv9+h7EHGPxZtfLkGZOoXl2GC/jgg41Bf +1H+1197yRrJgh/hQ5+HLcJHdC1WnIq4gYsVB40zUPE5gIAh77hXjljVwJpkcWCFHa7s aY0Mzd8/NQDl2OZuEb/9KzyVGDexAH9I0JRcopCeoZhKjBUL07McR/kq+YJbI4mMLDKY hvbUcelTq17VjQlVolqv6sLzwPZWCOcIFKhn52NkseQWcMwaWng6nwRpAOtgUOHcRb7z mTRIHQeiYxXLUlf3eMwN/g7W35QawrDvtl7q1kNgdEO/zhccxg5M4K+U4D5yO0EwIt8U okLA== 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=X4rue7s8VGFo2uJNEo23GfqXBOkg12BAA3jG74oSzB8=; b=m1dixWzHRKi/cO/18KGZNhN+QlQtBhXsHUCgfmymUXOcoUDcvlYHryr2mio8jMqsP/ HiYtC+1+KgC9u0LWHFuj+vu2CVgrNrFprEPM6sqJNg2cJblqWebCQkILQwDy6KJq+iit VJRTsUq9wKwQw3CIbESaQBn7Qu3HXR+MqNbI/TJ5eoXswzn+mdPMc43VjZAvlyvDlPZG GDUCCz70HTpArDCZCXIPmSTrzXsMW2KQIi/Ne8bnAWtCjlC5Z7rfW34A1TCOR5ZSrSHj B+hUNtPDR+/DOC9NXve5ZjrGi+VL9pWzO9fRYR/47bt7Eky0pZQKK/qRzphjwsgPq9T9 3/sw== X-Gm-Message-State: AOAM532lFv0k4dpQsc+dpN60wWqpC6tguC9M7irALu90UJrWxlLGBi8O W5xf0Y4t+FZxc3dnxceNczxZA7Cjc7Y50NcUJSc= X-Google-Smtp-Source: ABdhPJyHiX4IQtZA9Y/qm6fyxEqYFsJD8sUXs5nbKTOjVOeWENfQok4nirK8FUUoSr3Rd9tQ5vvdc5/qVbZZ1Uaztzg= X-Received: by 2002:a05:6512:1095:: with SMTP id j21mr354901lfg.16.1630192706060; Sat, 28 Aug 2021 16:18:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bernard Aboba Date: Sat, 28 Aug 2021 16:18:15 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: sframe@ietf.org Content-Type: multipart/alternative; boundary="00000000000029076e05caa6d139" Archived-At: Subject: Re: [Sframe] Status of the SFRAME WG X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2021 23:18:33 -0000 --00000000000029076e05caa6d139 Content-Type: text/plain; charset="UTF-8" "But in particular, I'm interested in supporting the chairs to restore the WG's momentum." [BA] Momentum comes from having an interesting problem to solve, as well as a path to solving it. SFrame promises to provide efficient E2E security over arbitrary transports (e.g. not just RTP). If it can achieve those goals, it can be an important part of the post-pandemic communications architecture. However, there are some basic gaps in the story. For example, how does a Web application decode and render an SFrame that is received over an arbitrary transport (e.g. HTTPS, WebTransport, WebRTC data channel, etc.)? Can't pass the SFrame to the MSE API, because it's not containerized. Can't decode the SFrame within WebCodecs API without decrypting it first (which today would require Javascript to have possession of the key, and also would make the decoded VideoFrame accessible to JS where it can be arbitrarily modified). If Javascript is untrusted (or if access to content is to be restricted) then that is problematic. (See: https://github.com/w3c/webcodecs/issues/41) One of the challenges of the post-pandemic world (in which streaming and RTC technologies are merging) is getting historically disparate protocols and APIs to work together. On Sat, Aug 28, 2021 at 1:47 PM Murray S. Kucherawy wrote: > Hi Bernard, > > On Sat, Aug 28, 2021 at 11:24 AM Bernard Aboba > wrote: > >> Murray -- >> >> Standards work often slows down in August as people take vacation. So it >> is not surprising to experience difficulty in getting a WG meeting together >> in early September. In the past I've had to cancel WG interims scheduled >> in August or early September, and just last week we had to extend a WGLC >> due to lack of responses. So some of what you are seeing may be the general >> slowdown in August. >> > > Sure, if I were only talking about August/September. But the last real > chatter on the WG list trailed off in March. > > Aside from that though, I do think there is reason to take another look at >> the problem definition in SFRAME WG. During the pandemic the disparate >> worlds of streaming and realtime communications have begun to merge, with >> the new category of "low latency streaming" emerging. We've seen developers >> taking a fresh look at problems such as video ingestion (e.g. RUSH, WISH) >> and low latency streaming (e.g. media over QUIC or WebRTC data channel). >> In the new architectures that are emerging, some of the traditional >> streaming architectural elements are being rethought. As one example, >> protocols such as WISH enable endpoints to upload simulcast or scalable >> video coding, rather than requiring a transcoding service. Also, APIs such >> as WebCodecs make it possible to decode and render video without >> containerization (as had been required when using MSE API). >> >> As these new ideas take shape in newly chartered WGs or BOFs, it may be >> appropriate to consider whether the SFRAME WG is targeting the right >> problems. Traditionally, streaming architectures have focused on the >> generalized transport of frames whereas RTP has forsaken generic >> encapsulations, choosing instead to customize packetization to each codec. >> As a result, at the IETF 111 AVTCORE meeting, Sergio presented SPacket, >> which while having quite a bit in common with SFrame, has security services >> occurring after packetization rather than before. >> >> However, even if SFrame turns out not to be suitable for use with RTP, it >> still may prove useful in the new architectures. As an example, in a low >> latency streaming use case requiring support for content protection (e.g. >> sports, concerts, etc.) it may be desirable for the downstream leg to >> bypass traditional content protection schemes based on containerization, >> just as next generation ingestion protocols may make it possible to bypass >> transcoding services. Could SFRAME play a role here? It may be worth >> considering. >> > > If there's a rechartering to be considered to (ahem) frame the working > group more appropriately, let's have that discussion. I'm happy to support > whatever path will enable meaningful work as the output. But in > particular, I'm interested in supporting the chairs to restore the WG's > momentum. > > -MSK > --00000000000029076e05caa6d139 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
"But in particular, I'm interested in supporting = the chairs to restore the WG's momentum."

[BA] = Momentum comes from having an interesting problem to solve, as well as a pa= th to solving it.=C2=A0

SFrame promises to provide= efficient E2E security over arbitrary transports (e.g. not just RTP).=C2= =A0 If it can achieve those goals, it can be an important part of the post-= pandemic communications architecture.

However, the= re are some basic gaps in the story.=C2=A0

For exa= mple, how does a Web application decode and render an SFrame that is receiv= ed over an arbitrary transport (e.g. HTTPS, WebTransport, WebRTC data chann= el, etc.)?=C2=A0

Can't pass the SFrame to the = MSE API, because it's not containerized.=C2=A0

Can't decode the SFrame within WebCodecs API without decrypting it fir= st (which today would require Javascript to have possession=C2=A0of the key= , and also would make the decoded VideoFrame accessible to JS where it can = be arbitrarily modified).=C2=A0 If Javascript is untrusted (or if access to= content is to be restricted) then that is problematic. (See:=C2=A0https://github.com/w3c/webc= odecs/issues/41)=C2=A0

One of the challenges o= f the post-pandemic world (in which streaming and RTC technologies are merg= ing) is getting historically disparate protocols and APIs to work together.=





=





=

On Sat, Aug 28, 2021 at 1:47 PM Murray S. Kucherawy <superuser@gmail.com> wrote:
Hi Berna= rd,

On Sat, Aug 28, 2021 at 11:24 AM Bernard Aboba <bernard.aboba@gmail.com>= wrote:
Murray --

Standards work often slows down in Au= gust as people take vacation. So it is not surprising to experience difficu= lty in getting a WG meeting together in early September.=C2=A0 In the past = I've had to cancel WG interims scheduled in August or early September, = and just last week we had to extend a WGLC due to lack of responses. So som= e of what you are seeing may=C2=A0be the general slowdown in August.=C2=A0<= /div>

Sure, if I were only talking ab= out August/September.=C2=A0 But the last real chatter on the WG list traile= d off in March.

Aside from that though, I do think the= re is reason to take another look at the problem definition in SFRAME WG.= =C2=A0 During the pandemic the disparate worlds of streaming and realtime= =C2=A0communications have begun to merge, with the new category of "lo= w latency streaming" emerging. We've seen developers taking a fres= h look at problems such as video ingestion (e.g. RUSH, WISH) and low latenc= y streaming (e.g. media over QUIC or WebRTC data channel).=C2=A0 In the new= architectures that are emerging, some of the traditional streaming archite= ctural=C2=A0elements are being rethought. As one example, protocols such as= WISH enable endpoints to upload simulcast or scalable video coding, rather= than requiring a transcoding service.=C2=A0 Also, APIs such as WebCodecs m= ake it possible to decode and render video without containerization (as had= been required when using MSE API).=C2=A0

As these= new ideas take shape in newly chartered WGs or BOFs, it may be appropriate= to consider whether the SFRAME WG is targeting the right problems.=C2=A0 T= raditionally, streaming architectures have focused on the generalized trans= port of frames whereas RTP has forsaken generic encapsulations, choosing in= stead to customize packetization to each codec.=C2=A0 As a result, at the I= ETF 111 AVTCORE meeting, Sergio presented SPacket, which while having quite= a bit in common with SFrame, has security services occurring after packeti= zation rather than before.

However, even if SFrame= turns out not to be suitable for use with RTP, it still may prove useful i= n the new architectures.=C2=A0 As an example, in a low latency streaming us= e case requiring support for content protection (e.g. sports, concerts, etc= .) it may be desirable for the=C2=A0downstream leg to bypass traditional co= ntent protection schemes based on containerization, just as next generation= ingestion protocols may make it possible to bypass transcoding services.= =C2=A0 Could SFRAME play a role here? It may be worth considering.

If there's a rechartering to be consider= ed to (ahem) frame the working group more appropriately, let's have tha= t discussion.=C2=A0 I'm happy to support whatever path will enable mean= ingful work as the output.=C2=A0 But in particular, I'm interested in s= upporting the chairs to restore the WG's momentum.

-MSK
--00000000000029076e05caa6d139--