From nobody Tue Sep 1 02:24:06 2020 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 BD63C3A0E80; Tue, 1 Sep 2020 02:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 pa5dPxlqTjap; Tue, 1 Sep 2020 02:23:53 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30053.outbound.protection.outlook.com [40.107.3.53]) (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 77CD33A0E59; Tue, 1 Sep 2020 02:23:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VDd75P89P1lRWJgyFt3VRWvHM9o70UaRnKXJcRITmlsUVAMWZsNz8zknFd3njDOHanG9CS4uQciZFU2+zSF1QKC4HhDYuGSrWY26Iq7NLKJri83ig4yU8FPK+fJE7zoKGoPgPwK/b7SDDeEM4e77mVwHC8xZecFObqtUWSDd/+xezF0XfqMFOj8lH96golZjoxLzrZ8J77iLlHhmiMp+GEQzBQgoi1OiztBQI/eUMvuRQE8UIVz050GragB6sqXeaq7BrEr6hu8nXWe9sFyakem38t7qQPSUkyxEJdDkQu7YL+9Ud20lngofnXEVcUZuKH0lXUBdk0zJ3OG9oL7zuw== 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=IGmOrXvdoHSWhdcP4fQrr83h0VzcFNDJPfeDRV1lq/o=; b=hPW3MS6iNS2sm8ZZ/1h27D6fflkANGHfrK7ivhQ6fqpHC6tDZpwLpUQbf1GA9jHNVUDCS2PxsnGSnGq6GXy7VJgubBe1B1efBQt+UWztpdfeWnXUrMuCmh5ck0GkRplUXb+ovqRSw0XogX12a2rBEe0VmliPDbCPGfyqac/EPAkCxcejbs4KA3MYC++8ioMyGIT3FeLo3DgKCjvvgsoS96TH4TCWat6XmFObwG2TsXvKSlvLUTnI0v6qwKPH0sGyocbLu8KLAgKIu32cMqakuIJSv6I5rgLM7oUiDTe0yFx05yhDUzknV9CZQOmu5OL1fAFJ08OfBaAga9NtzYFMAA== 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=IGmOrXvdoHSWhdcP4fQrr83h0VzcFNDJPfeDRV1lq/o=; b=IjMll9g7uW/nDW6sMpxb6ms5q0VsJME4TQ3XlmRTl6wRslr8gpDUejSHLtfWonmwaOzqdZs2RBK5HC2xDS3CRnEHqaYHP5773pFOheWx5LSV1+0KIFZPeSq/dVlkcOPkLnReUEocbb5iUTViYICBhJCBw5AeKgzj7H91I18KH14= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR07MB3449.eurprd07.prod.outlook.com (2603:10a6:7:38::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.6; Tue, 1 Sep 2020 09:23:47 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::b56f:9a8e:3399:aaa3]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::b56f:9a8e:3399:aaa3%7]) with mapi id 15.20.3348.014; Tue, 1 Sep 2020 09:23:47 +0000 From: Magnus Westerlund To: "rlb@ipv.sx" CC: "Alex.GOUAILLARD@cosmosoftware.io" , "ben@nostrum.com" , "emadomara=40google.com@dmarc.ietf.org" , "dispatch@ietf.org" , "sframe@ietf.org" , "sergio.garcia.murillo@gmail.com" Thread-Topic: [Sframe] [dispatch] SFRame Next Steps (was SFrame proposed WG charter) Thread-Index: AQHWa2UvSRWiVT7MukOqMgZDT9IOv6kqyBeAgACYmgCAAjbMgIAHB3KAgB3KAwCAABpHgIABKSkA Date: Tue, 1 Sep 2020 09:23:47 +0000 Message-ID: <18af04caed9687f6eceee6576f85f9d40e72019a.camel@ericsson.com> References: <69181ed1-d72a-99de-8b4d-9e10276ced91@gmail.com> <771e108a9f25c1bec04d5fcdad58eb55bbb1533d.camel@ericsson.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2 authentication-results: ipv.sx; dkim=none (message not signed) header.d=none;ipv.sx; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.83] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0e963e35-e203-4022-40e1-08d84e58bb1c x-ms-traffictypediagnostic: HE1PR07MB3449: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jtW0tjK8kHIHeioh3v/GN0eOkh0ykjZEkNNc2K+C3prkjlQt8mSyL+BDzxLW0wbP6e0s1SxpLeTLXqIAzHtgYvMJpUFmsRW8hOFTTWDOxsBrwYcpE66smeU4y5MvIzNHnRpuRS5L0RdQxX4gpi/y/lSrQRl6KwJ3+ia3cgY2b55had1cyFi3vR8HXqCnVKS8sO17OBF6GYwAt4IzPHV1NAxsWpnrdGUZi6ohu0a1zF55kUTc4ye2NBeu8jOvVHP8CDU+ngt3gnEfyeBy2h7VrU7yKZfHx8MLNiqwkK+ztTYg70ujxKaoVv3H3SZgkZT2UCJYZ6JcbFlDNPbRzdXgYygqk2jn8OGGbnVpdDsWJ71TNUnybCa+6FSraKXc+CWS x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(39860400002)(346002)(366004)(376002)(2906002)(66946007)(186003)(6512007)(54906003)(26005)(66476007)(316002)(6506007)(478600001)(64756008)(6486002)(91956017)(66446008)(66556008)(6916009)(76116006)(2616005)(36756003)(8676002)(44832011)(71200400001)(5660300002)(8936002)(83380400001)(4326008)(86362001)(99106002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: PpG0f0+HPc8iku6ca6nrBLNR1zNDGvlNF5v8bEH5EVBFeUHmEVbFgNpzK379hUEurKi3I8jOcYv9m0iFoDtGrHM0VTlUUOAzarnZu8QfUmD4FaOU9HPkQaNnzT+99RWODZ9KEmhP61MfePkToLW3gcCVcWHEWqSQ9KEZFXjOqslCbyDnRg1j2SPS8JNjr+p4Pl4maRF6CycNIN1kCltKuMZAZ+Rt4y5v7OCdOkrqtQn4M+YaJiaP+E/9+5DGe+ze6jd01Wk3J4FRA8nLi0Bbgak22WlgC6lusZJcyhWqUdEUAtbwVdE6VhrrNFyjbMTy1Z7JDgVN0DHPYBCkF2DLgErhJZbICbk3zRqO5lV9lnAjVH54s+avoF4HdOl77cmtj1L/XDBl06LLobublnTB8SIs3eHahetIlQYQGs0THX7m83FZ9ZbP7CRJFq8wfQ4SuMAbE527NRLCtIhFGZYYF84+ZtUwfAIgAcjdTcTKvhvy8Bbdg0GzfOFj20MCQcJVrnxYbOwjZ1d4752kFFR/pNEksFC13oIFAkmEnUjdUHp3mFpY2t/8DsxvK4GBFodAm/y6EMS7dsFu/OCSK5JGdP8GziGjs1rz8mIaawkfIqVdiIKN7mqudUbGQXZcWzt8ncWwJQ37ZFV5qtCABTFZXw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <4CD0C54A3BB524408D3A153D40C5B826@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0e963e35-e203-4022-40e1-08d84e58bb1c X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2020 09:23:47.5415 (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: qt1WCToVxpMSxtXI5Vi3yl+yBTfsFn+63d51s74z9AvrTbgNE4Qt8rUYU3aPssL76AV48wrLaS8NOBtjWiiJekawBg97ArNgsc5K6jIji7g= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3449 Archived-At: Subject: Re: [Sframe] [dispatch] SFRame Next Steps (was SFrame proposed WG charter) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 09:24:02 -0000 SGksIA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KT24gTW9uLCAyMDIwLTA4LTMxIGF0IDExOjQw IC0wNDAwLCBSaWNoYXJkIEJhcm5lcyB3cm90ZToNCj4gSGkgTWFnbnVzLA0KPiANCj4gSSB0aGlu ayB0aGUgaW50ZW50IGhlcmUgaXMgdG8gaGF2ZSBhIG1lY2hhbmlzbSB0aGF0IHByb3ZpZGVzIGEg c3Vic2V0IG9mIHRoZQ0KPiBzZWN1cml0eSBwcm9wZXJ0aWVzIHJlcXVpcmVkIGZvciBhIGdpdmVu IHNjZW5hcmlvLCBidXQgd2hpY2ggY2FuIGJlIGF1Z21lbnRlZA0KPiB3aXRoIGFkZGl0aW9uYWwg bWVjaGFuaXNtcyB0byBwcm92aWRlIHRoZSByZXN0LiAgRm9yIGV4YW1wbGUsIGV2ZW4gaW4gdGhl IG1vc3QNCj4gb2J2aW91cyBTRnJhbWUrU1JUUCBjYXNlLCB0aGVyZSdzIGEgZGl2aXNpb24gb2Yg bGFib3IgYmV0d2VlbiB0aGUgdHdvDQo+IHByb3RvY29scywgd2hlcmUgU0ZyYW1lIG9ubHkgcHJv dGVjdHMgY29udGVudCwgYW5kIFNSVFAgYWxzbyBwcm90ZWN0cyB0aGUgUlRQDQo+IGhlYWRlciBh bmQgZ3VhcmRzIGFnYWluc3QgcmVwbHkgYnkgbmV0d29yayBhdHRhY2tlcnMuDQoNClllcywgSSB0 aGluayB0aGF0IGlzIGZpbmUuIEhvd2V2ZXIsIHRoYXQgd2lsbCByZXF1aXJlIHRoYXQgeW91IGRp c2N1c3MgdGhlDQpsYXJnZXIgc2V0IG9mIHRocmVhdHMsIGFuZCB0aGVuIGJlIGV4cGxpY2l0IHdo YXQgU0ZSQU1FIHNvbHZlcyBhbmQgd2hpY2ggaGF2ZSB0bw0KYmUgc29sdmVkIGJ5IHRoZSB0cmFu c3BvcnQgbWVjaGFuaXNtIHVzZWQgdG8gbW92ZSB0aGUgU0ZSQU1FIG1lc3NhZ2VzLiANCg0KPiAN Cj4gU28gaW4gYSBzZW5zZSBpdCBpcyBhbiBpbnRlcnNlY3Rpb24gKGluIHRoYXQgaXQgZG9lcyBz b21ldGhpbmcgdGhhdCBpcyBuZWVkZWQNCj4gYnkgYWxsIHRoZSB1c2UgY2FzZXMpLCBidXQgaXQg bWlnaHQgbmVlZCBvdGhlciB0aGluZ3MgdG8gcHJvdmlkZSBhbGwgdGhlDQo+IHByb3BlcnRpZXMg eW91IG5lZWQgaW4gYSBnaXZlbiBzY2VuYXJpby4NCg0KWWVzLCBTRlJBTUUgc29sdmVzIHRoZSBp bnRlcnNlY3Rpb24gYW5kIHRob3NlIHRocmVhdCB0aGF0IGJlbG9uZyB0byB0aGUgVW5pb24NCmJ1 dCBhcmUgb3V0c2lkZSBvZiBpbnRlcnNlY3Rpb24gd2lsbCBiZSByZXF1aXJlbWVudCBvbiB0aGUg ZXh0ZXJuYWwgbWVjaGFuaXNtcy4NCg0KDQpDaGVlcnMNCg0KTWFnbnVzIFdlc3Rlcmx1bmQgDQoN Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KTmV0d29ya3MsIEVyaWNzc29uIFJlc2VhcmNoDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpFcmljc3NvbiBBQiAgICAgICAgICAgICAgICAgfCBQaG9uZSAgKzQ2IDEwIDcxNDgyODcN ClRvcnNoYW1uc2dhdGFuIDIzICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0KU0Ut MTY0IDgwIFN0b2NraG9sbSwgU3dlZGVuIHwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmlj c3Nvbi5jb20NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQo= From nobody Fri Sep 4 03:23:23 2020 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 007753A0965 for ; Fri, 4 Sep 2020 03:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 NYTW6iBKC0c8 for ; Fri, 4 Sep 2020 03:23:21 -0700 (PDT) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 63C753A098B for ; Fri, 4 Sep 2020 03:23:21 -0700 (PDT) Received: by mail-ej1-x634.google.com with SMTP id gr14so6765486ejb.1 for ; Fri, 04 Sep 2020 03:23:21 -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=FAAcM01ZKbg5n8nUMlRo3yT1A58MKRycs1dwTuLed6A=; b=tOdJdpa/oImG8ZI/q+HKaKRWha1r1vtt+a4Nw7IN3UD7UZbkiwDdKrreZcpik/qJJf dNo/2Uebfb9ML2Ag6tnj69Fx7GO8cCQMRGi1dgyfhA1zmfxlYyLMMVzmpHaYqg6QifBB 8sNgQMWiBHnT2GwkYk33xq9mjj6B87uZ4+Gowhu4bmoslNC9cyYsfEm+Ijo+Vdop9Krq ZNXdHqHpxyRwr71AmZDWKBPDtiVxzEFe/zbeC8G91miN5lM3HMspIiHSaXqNbwPvuqpV Q8mFjVcljcFOg9CpEpJSaiN2fTb4RQMbF04tVQ9WWnr3waqBK38D9aaSQrt4+HJsZQa2 K3iQ== 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=FAAcM01ZKbg5n8nUMlRo3yT1A58MKRycs1dwTuLed6A=; b=W88oky5Q8XdJfREw4YGmXsjzO7H0Ecg7g3pWUeH+99Sqlol7eAxRp0LY3RVV08oMmt mGijjO7bxjE50oge74u2VEY2/JjnlE4ftBFlDDwQMevMJbFbnYa1pClFiBYSRNUCSow+ 2qCLEvEYEaTCOraq7nSUKVKCXUVCllaZJuglhIyrvNTfJkOSiwMa8OE249S7sOpWw99c d5Dgu07aEVL3TfPsUAKD1QtIVt7E5rjByJV34eSAcJbEigZrZ1MoWAAebOmekbpwnauX 7sh2R9BGoa1FgrqThxaohh1TAlfZJuAP6wQr3YwTSvB1lAaTefb6jga16SGkma9/9VpY BpTA== X-Gm-Message-State: AOAM533ppWm302E5rrUVvleKAlyaU9IG5tYUibxTDKYL/E96jTusyDmi wuUaKy/vQKvkr/D40s62hzp8jyoPfTlzl+c6BaUaeEZV X-Google-Smtp-Source: ABdhPJwlfduYhORumSNOaZNr4erZCM8pJwgO+YR/btccYOI1RB2dvhLpocke6Ug2wVW1ORKnTpPilN4KtxMIjIifw/k= X-Received: by 2002:a17:907:7090:: with SMTP id yj16mr6486221ejb.73.1599214999567; Fri, 04 Sep 2020 03:23:19 -0700 (PDT) MIME-Version: 1.0 From: Franziskus Kiefer Date: Fri, 4 Sep 2020 12:23:08 +0200 Message-ID: To: sframe@ietf.org Content-Type: multipart/alternative; boundary="000000000000f800e005ae7a41a1" Archived-At: Subject: [Sframe] charter feedback X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2020 10:23:23 -0000 --000000000000f800e005ae7a41a1 Content-Type: text/plain; charset="UTF-8" Hi all, First, thanks for working on this. Wire is currently considering sframe for some use cases. Looking at the charter I noticed two things: The charter currently doesn't talk about authentication and to which extent the WG wants to look at it. While authenticity might be implicit through the used keys the sframe draft currently also uses signatures. I'm missing a statement about the process followed by the WG. End-to-end encrypted conferencing is a relatively new topic without much research around threat models. I therefore think that a process that validates the threat model and the proposed solution is warranted. This might not have the same extent as for TLS or MLS, but would still be good to have. Cheers, Franziskus --000000000000f800e005ae7a41a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

First, thanks for wo= rking on this.
Wire is currently considering sframe for some use = cases.

Looking at the charter I noticed two th= ings:

The charter currently doesn't talk about authentica= tion and to which extent the WG wants to look at it. While authenticity mig= ht be implicit through the used keys the sframe draft currently also uses s= ignatures.

I'm missing a statement about t= he process followed by the WG. End-to-end encrypted conferencing is a relat= ively new topic without much research around threat models. I therefore thi= nk that a process that validates the threat model and the proposed solution= is warranted. This might not have the same extent as for TLS or MLS, but w= ould still be good to have.

Cheers,
Fran= ziskus
--000000000000f800e005ae7a41a1-- From nobody Fri Sep 4 04:23:36 2020 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 24C963A0D51 for ; Fri, 4 Sep 2020 04:23:35 -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=cosmosoftware-io.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 u-sIJrHXF2cB for ; Fri, 4 Sep 2020 04:23:33 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 69E7B3A0D6C for ; Fri, 4 Sep 2020 04:23:33 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id m12so2564984otr.0 for ; Fri, 04 Sep 2020 04:23:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cosmosoftware-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WOXmXzlOXyivL3JK0ImGZ/5DkGzFRkrORefKmBcfQYo=; b=UFd0FkswbqGWwYZcuhYgX/ptwmT8eKXsPyE73Sme7rY9tcZjMwhWDK+rwQhUrzzoy+ tU3GtfigkSiSX9u4N2GGxkfx3koYfaTmuAYlSWlpffPU+k/nQK4z9GGemMbo5pT0iWHq NfaG7dIr02SCeUEcPEnLFUc+WLBJHtXpkPtRBuFgcLIpY4sSECYJLitiOnJW3bFNl/xs ylLw+LWEHsqe0kn94MJi+1p7HBL7wXn3zZ7tYXzQHidmXFsr/sBABF5gxUuW5LPbOkER Qu0ndSapCihgVHXQ/hS975p+FkOHqI20rDvljhnJmh885+HH9RHw6eehUymu1A2XqUx4 HHIg== 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=WOXmXzlOXyivL3JK0ImGZ/5DkGzFRkrORefKmBcfQYo=; b=n+X7yvG7sSa3y+Yc0bYaAjwUIovuLhVDGYiwz307kBGgcsOl4bDCWmkvbVp0W9R6mf JSnTjweeP9dOiAyvPddyk42S8Qy1Yd/Eh3JSEThmyt6Tq/ktzwyHomR0YvHDp5nvIjmM 5t2zkAzeWhg3wTYCdnYEJEbvfXAVRp4Tfp/SHnSH3wZtoiao+HWzJb3+haRQVYyA38+v zj24LE5xoKlr0Xi3oci/m81HXEtyW9+xs3ijpOEN2pL5ODDkRuibU00P6tEYGE2iXOLb 5kItBmuQaxQ5eIIIJbOfnzkGGPnThFOFJ+XygfpyIr+ExUXsRuyrJ+IK89GoJK829dmk AmOQ== X-Gm-Message-State: AOAM531K+r0w0sdqUVuBgt37LQD/yMV1lWHoGG59+o3n9hR6bB6gaR+n 7WLpT5puudbE5xbOvqu4VjO+UaXgM5DptmIDIqJnnQ== X-Google-Smtp-Source: ABdhPJw/SJWQqwVoGaI/DmRFBAHwyf9gvTmmBpRgNBfyMJmfVzBRqYUCUvkgXshfpYnXrW9FCWWOdxvZ/K6BmjNMHKA= X-Received: by 2002:a9d:621a:: with SMTP id g26mr5309749otj.209.1599218612579; Fri, 04 Sep 2020 04:23:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alexandre GOUAILLARD Date: Fri, 4 Sep 2020 19:23:21 +0800 Message-ID: To: Franziskus Kiefer Cc: sframe@ietf.org Content-Type: multipart/alternative; boundary="00000000000052457305ae7b199b" Archived-At: Subject: Re: [Sframe] charter feedback X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2020 11:23:35 -0000 --00000000000052457305ae7b199b Content-Type: text/plain; charset="UTF-8" Hi franz., Thank you for your interest and the kind words. "Conferencing" is certainly a topic of interest, and i understand the focus of wire. SFrame can certainly be used in that context. However, there are other use cases than conferencing where media encryption is of interest, including but not limited to streaming/broadcasting and then of course all the hybrid use cases we start seeing emerging (watch parties, webinars, ....). We designed SFrame itself to refer ONLY to the media encryption part, and be as much as possible media transport agnostic, and use case/threat model/trust model agnostic, where the precedent attempt was extremely focussed on RTP-based conferencing. Eventually, each use case (e.g. conferencing) should have additional documents to come up to a full system whose properties could be verified, but we did not want to restrict the charter to a single use case. Right now, emad is working on the conferencing use case with sergio, and you might want to liaise with them on that specific topic. One document about how SFrame can be used with RTP, and, seprately, with MLS including the corresponding threat model is in progress. I think this is what you are looking for. In parallel, work is being done on application to SFrame for streaming/broadcasting and how it relates/overlaps with existing DRM solutions today in the bigger context. This will also hopefully have its own set of document. EVentually all would have the media encryption, SFrame, in common. Hope this helps. On Fri, Sep 4, 2020 at 6:23 PM Franziskus Kiefer wrote: > Hi all, > > First, thanks for working on this. > Wire is currently considering sframe for some use cases. > > Looking at the charter I noticed two things: > > The charter currently doesn't talk about authentication and to which > extent the WG wants to look at it. While authenticity might be implicit > through the used keys the sframe draft currently also uses signatures. > > I'm missing a statement about the process followed by the WG. End-to-end > encrypted conferencing is a relatively new topic without much research > around threat models. I therefore think that a process that validates the > threat model and the proposed solution is warranted. This might not have > the same extent as for TLS or MLS, but would still be good to have. > > Cheers, > Franziskus > -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --00000000000052457305ae7b199b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi franz.,

Thank you for your interest = and the kind words.

"Conferencing" is ce= rtainly a topic of interest, and i understand the focus of wire. SFrame can= certainly be used in that context.

However, there= are other use cases than conferencing where media encryption is of interes= t, including but not limited to streaming/broadcasting and then of course a= ll the hybrid use cases we start seeing emerging (watch parties, webinars, = ....).

We designed SFrame itself to refer ONLY to = the media encryption part, and be as much as possible media transport agnos= tic, and use case/threat model/trust model agnostic, where the precedent at= tempt was extremely focussed on RTP-based conferencing.

Eventually, each use case (e.g. conferencing) should have additional= =C2=A0documents to come up to a full system whose properties could be verif= ied, but we did not want to restrict the charter to a single use case.

Right now, emad is working on the conferencing use cas= e with sergio, and you might want to liaise with them on that specific topi= c. One document about how SFrame can be used with RTP, and, seprately, with= MLS including the corresponding threat model is in progress. I think this = is what you are looking for.

In parallel, work is = being done on application to SFrame for streaming/broadcasting=C2=A0and how= it relates/overlaps with existing=C2=A0DRM solutions today in the bigger= =C2=A0context. This will also hopefully have its own set of document. EVent= ually all would have the media encryption, SFrame, in common.
Hope this helps.



<= div class=3D"gmail_quote">
On Fri, Sep= 4, 2020 at 6:23 PM Franziskus Kiefer <franziskuskiefer@gmail.com> wrote:
Hi all,

First, thanks = for working on this.
Wire is currently considering sframe for som= e use cases.

Looking at the charter I noticed = two things:

The charter currently doesn't talk about auth= entication and to which extent the WG wants to look at it. While authentici= ty might be implicit through the used keys the sframe draft currently also = uses signatures.

I'm missing a statement a= bout the process followed by the WG. End-to-end encrypted conferencing is a= relatively new topic without much research around threat models. I therefo= re think that a process that validates the threat model and the proposed so= lution is warranted. This might not have the same extent as for TLS or MLS,= but would still be good to have.

Cheers,
Franziskus
--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--00000000000052457305ae7b199b-- From nobody Fri Sep 4 05:15:53 2020 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 67B163A074B for ; Fri, 4 Sep 2020 05:15:52 -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 k54i2gWK6-X5 for ; Fri, 4 Sep 2020 05:15:50 -0700 (PDT) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 58DB63A05DE for ; Fri, 4 Sep 2020 05:15:50 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id a12so5830886eds.13 for ; Fri, 04 Sep 2020 05:15:50 -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=O7O80SleAm1KWzRcTmF3bqD9AsLlHYofHv+XUe6P/z8=; b=uzfbqLG3fe0DlI97uDz8gd9HGLEEGhlVIqWPVMiKvJASzjVAHXA/Pr58PvnxAHtis6 54Etca/8hONnqkRWRHOxGmJL0kD01zA0NYHRYhCAHvJPRwwcNU/e515ICDM3lyyABXUt Bmg9IhjZWr92BYTO4K2n3gDf6ExHQ8mbsyL51FT0/VoAehiNN9bgIsLI3NuaCyeTWS2n wIGfgg5gDF05ap1Tyk58J2+j/k5fpl/LAhLFSAf6ZKjsmnIzzeK/tS3qeHl+6rLRKzt/ ueSQocIATI4SeQsfgOZqyzJLmY8e/8K8n3gqVN7jh2UE9HHxpUznzbb+hUYW3hj78bhr 60Ww== 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=O7O80SleAm1KWzRcTmF3bqD9AsLlHYofHv+XUe6P/z8=; b=AXl+SNP/7NI0Wmkja2MzTUunkP3ry0IwtL4dyzQzzhplweHaMxJWZtFj0JHr05CEOe R/bFP7KtdB7yKuCeYNXRMMphna4KoJYuv4ThS3YQjT5MsuqMgpt57HMhIw4+S4xfv/21 Mm+7D9kvuviCfOSgfJ0JUu1H8kCLNCOm2WdUCZFvB6aLUgWL3mnb0hD0O+nTVMsnkonA PXVItf+qClr8RBaj8f7EnLrO/IcccAfvtBENSYd3GzUYxX7RhqiYwzL7vDi5I1nl0Hi0 DIqcSvGapX5k37BRFAzbmFqu+DIMUhcAKzMZ5aLpmUiphZGx7MSo3rif7+sAm5o0x7Iz AxqQ== X-Gm-Message-State: AOAM533wlaiKZ1qpb/lewW1iZIpcm+7WtBo7JjkOawh+c0l+hGwa8mIO a3leLOdJs9cNurRYO6PfvIc4w+PgBPs/2XFBXXZLsdXE5Fw= X-Google-Smtp-Source: ABdhPJxKseflOl2ltJmQktyDaHrMfIkehh8ydJPj21S30ENMTfuUvj4RqWg+cVIT9VtaBoYyaxpE0HBofZ3vJt8MuQg= X-Received: by 2002:a05:6402:184d:: with SMTP id v13mr8392674edy.240.1599221748735; Fri, 04 Sep 2020 05:15:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Franziskus Kiefer Date: Fri, 4 Sep 2020 14:15:37 +0200 Message-ID: To: Alexandre GOUAILLARD Cc: sframe@ietf.org Content-Type: multipart/alternative; boundary="0000000000004021a605ae7bd49c" Archived-At: Subject: Re: [Sframe] charter feedback X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2020 12:15:52 -0000 --0000000000004021a605ae7bd49c Content-Type: text/plain; charset="UTF-8" Hi Alexandre, thanks for the response. I totally agree that the charter shouldn't restrict the use cases here. Conferencing was really meant as an example (bad phrasing on my side, though it's of course an important use case for us). But the charter can set out the process taken by the WG. And all use cases here should profit from this (i.e. making sure that the threat modeling and solution for each use case are vetted by other parties, in particular academia). > Right now, emad is working on the conferencing use case with sergio, and you might want to liaise with them on that specific topic. One document about how SFrame can be used with RTP, and, seprately, with MLS including the corresponding threat model is in progress. I think this is what you are looking for. I currently only know about https://github.com/eomara/sframe. Is there any other draft in progress? Best, Franziskus On Fri, 4 Sep 2020 at 13:23, Alexandre GOUAILLARD < Alex.GOUAILLARD@cosmosoftware.io> wrote: > Hi franz., > > Thank you for your interest and the kind words. > > "Conferencing" is certainly a topic of interest, and i understand the > focus of wire. SFrame can certainly be used in that context. > > However, there are other use cases than conferencing where media > encryption is of interest, including but not limited to > streaming/broadcasting and then of course all the hybrid use cases we start > seeing emerging (watch parties, webinars, ....). > > We designed SFrame itself to refer ONLY to the media encryption part, and > be as much as possible media transport agnostic, and use case/threat > model/trust model agnostic, where the precedent attempt was extremely > focussed on RTP-based conferencing. > > Eventually, each use case (e.g. conferencing) should have > additional documents to come up to a full system whose properties could be > verified, but we did not want to restrict the charter to a single use case. > > Right now, emad is working on the conferencing use case with sergio, and > you might want to liaise with them on that specific topic. One document > about how SFrame can be used with RTP, and, seprately, with MLS including > the corresponding threat model is in progress. I think this is what you are > looking for. > > In parallel, work is being done on application to SFrame for > streaming/broadcasting and how it relates/overlaps with existing DRM > solutions today in the bigger context. This will also hopefully have its > own set of document. EVentually all would have the media encryption, > SFrame, in common. > > Hope this helps. > > > > On Fri, Sep 4, 2020 at 6:23 PM Franziskus Kiefer < > franziskuskiefer@gmail.com> wrote: > >> Hi all, >> >> First, thanks for working on this. >> Wire is currently considering sframe for some use cases. >> >> Looking at the charter I noticed two things: >> >> The charter currently doesn't talk about authentication and to which >> extent the WG wants to look at it. While authenticity might be implicit >> through the used keys the sframe draft currently also uses signatures. >> >> I'm missing a statement about the process followed by the WG. End-to-end >> encrypted conferencing is a relatively new topic without much research >> around threat models. I therefore think that a process that validates the >> threat model and the proposed solution is warranted. This might not have >> the same extent as for TLS or MLS, but would still be good to have. >> >> Cheers, >> Franziskus >> -- >> Sframe mailing list >> Sframe@ietf.org >> https://www.ietf.org/mailman/listinfo/sframe >> > --0000000000004021a605ae7bd49c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alexandre,

thanks for the= response.
I totally agree that the charter shouldn't restric= t the use cases here. Conferencing was really meant as an example (bad phra= sing on my side, though it's of course an important use case for us).
But the charter can set out the process taken by the WG. And all u= se cases here should profit from this (i.e. making sure that the threat mod= eling and solution for each use case are vetted by other parties, in partic= ular academia).

> Right now, emad is working on= the conferencing use case with sergio, and you might want to liaise with them on that specific topic. One document about how SFrame can be used with RTP, and, seprately, with MLS=20 including the corresponding threat model is in progress. I think this is what you are looking for.

I currently only know a= bout https://github.com/eomara= /sframe. Is there any other draft in progress?

=
Best,
Franziskus


On Fri, 4 Sep 2020 at 13:23, A= lexandre GOUAILLARD <Alex.GOUAILLARD@cosmosoftware.io> wrote:
Hi fran= z.,

Thank you for your interest and the kind words.

"Conferencing" is certainly a topic of inter= est, and i understand the focus of wire. SFrame can certainly be used in th= at context.

However, there are other use cases tha= n conferencing where media encryption is of interest, including but not lim= ited to streaming/broadcasting and then of course all the hybrid use cases = we start seeing emerging (watch parties, webinars, ....).

We designed SFrame itself to refer ONLY to the media encryption par= t, and be as much as possible media transport agnostic, and use case/threat= model/trust model agnostic, where the precedent attempt was extremely focu= ssed on RTP-based conferencing.

Eventually, each u= se case (e.g. conferencing) should have additional=C2=A0documents to come u= p to a full system whose properties could be verified, but we did not want = to restrict the charter to a single use case.

Righ= t now, emad is working on the conferencing use case with sergio, and you mi= ght want to liaise with them on that specific topic. One document about how= SFrame can be used with RTP, and, seprately, with MLS including the corres= ponding threat model is in progress. I think this is what you are looking f= or.

In parallel, work is being done on application= to SFrame for streaming/broadcasting=C2=A0and how it relates/overlaps with= existing=C2=A0DRM solutions today in the bigger=C2=A0context. This will al= so hopefully have its own set of document. EVentually all would have the me= dia encryption, SFrame, in common.

Hope this helps= .



<= div dir=3D"ltr" class=3D"gmail_attr">On Fri, Sep 4, 2020 at 6:23 PM Franzis= kus Kiefer <franziskuskiefer@gmail.com> wrote:
Hi all,

<= /div>
First, thanks for working on this.
Wire is currently co= nsidering sframe for some use cases.

Looking a= t the charter I noticed two things:

The charter currently doe= sn't talk about authentication and to which extent the WG wants to look= at it. While authenticity might be implicit through the used keys the sfra= me draft currently also uses signatures.

I'= ;m missing a statement about the process followed by the WG. End-to-end enc= rypted conferencing is a relatively new topic without much research around = threat models. I therefore think that a process that validates the threat m= odel and the proposed solution is warranted. This might not have the same e= xtent as for TLS or MLS, but would still be good to have.

Cheers,
Franziskus
--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--0000000000004021a605ae7bd49c-- From nobody Fri Sep 4 05:22:19 2020 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 57AB23A079F for ; Fri, 4 Sep 2020 05:22:18 -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=cosmosoftware-io.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 gAAKKV4cLoHt for ; Fri, 4 Sep 2020 05:22:16 -0700 (PDT) Received: from mail-oo1-xc2d.google.com (mail-oo1-xc2d.google.com [IPv6:2607:f8b0:4864:20::c2d]) (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 B6DB23A0763 for ; Fri, 4 Sep 2020 05:22:16 -0700 (PDT) Received: by mail-oo1-xc2d.google.com with SMTP id u28so1563031ooe.12 for ; Fri, 04 Sep 2020 05:22:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cosmosoftware-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mnh9pwmrknlrp1+4aAv/h6ZZ2RerV5Z+Xd1/zyPsZL8=; b=z5dZfoSKCxzreHdHZsU5Zu5RhR/xL4qFGHAv+nNalZnTxsiZuOhsRJ4sVJECNBefkO C/DDr9+uXHatzMKKO8XXqf0oxFlpNicPWBbUBTRqsVx0J5UiDUQsRxMg8qLIgSB0JsFO nZ2HOqniKqcp/RQB0FZv/1KKSGhszOT05/WHaGn9/CLpMHfBxrC0nmyo88mWU5gRJGPD COzHiil/xkSL2no2XOFjOJYIojQHeykBNGqc9VosK1tdmZGnkow9Pdo6aSACuLnyOurI 1WSkjkSQP1ITB1eYuYjlJvCnSUPUhXx0DKKK5bXZ7Ztd24mod/EJDZIY6FFuvFQ5DAd6 7CJQ== 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=mnh9pwmrknlrp1+4aAv/h6ZZ2RerV5Z+Xd1/zyPsZL8=; b=AxSIPljng5UKtdJ4TKYH/CTy/aE2DLiBIL9/8mJN3iv3jVkmL7XNcemfbCbmeQxm56 f6qZXUXzvRtpqZRRHsMDOvtgRx2zdCPiElh63ClTmKHM5yIFpS1T/rdGkx4ZrAvAMwwk xjIMFlBY8Zv7Um9FgUDlpzcRRk3yy4nmmd2akHNN9MmlRXgy3axXam0HdMNpmhIPAHvX W5hdBLg7gxuVX8hk0KO4bkKZVwMmKtk60TNPitRKG6ZL2DZPD9Txt7fttMuLO6ggOh+R m9FkkqcSSPdIz1xo5Efs2F4GBcSBdUCfs7ojVrvpgMch+Tns31+5LU9L38YhYL1FHfzF EBLA== X-Gm-Message-State: AOAM531kpnrIOfS1gyaYBFI1UA61LkgMkzZibZQ1Kvp/BNWn+aQZdHee UscpLmT2B6gdYUYufGlQ5PrqA2rahdUXo8vS21vsrA== X-Google-Smtp-Source: ABdhPJxp7E4OIDhB1mRnFj/EZeYXwSGSB2PvZr6lvH2sommvjCwT3JeTH3PvlB4BebRR1VRSHTNTt6WqfmEcmgcNlrQ= X-Received: by 2002:a4a:6759:: with SMTP id j25mr5637175oof.14.1599222135871; Fri, 04 Sep 2020 05:22:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alexandre GOUAILLARD Date: Fri, 4 Sep 2020 20:22:05 +0800 Message-ID: To: Franziskus Kiefer Cc: sframe@ietf.org Content-Type: multipart/alternative; boundary="000000000000536fc205ae7bebce" Archived-At: Subject: Re: [Sframe] charter feedback X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2020 12:22:18 -0000 --000000000000536fc205ae7bebce Content-Type: text/plain; charset="UTF-8" > > But the charter can set out the process taken by the WG. And all use cases > here should profit from this (i.e. making sure that the threat modeling and > solution for each use case are vetted by other parties, in particular > academia). > I think our goals are aligned. > > > Right now, emad is working on the conferencing use case with sergio, and > you might want to liaise with them on that specific topic. One document > about how SFrame can be used with RTP, and, seprately, with MLS including > the corresponding threat model is in progress. I think this is what you are > looking for. > > I currently only know about https://github.com/eomara/sframe. Is there > any other draft in progress? > Yes. You might want to contact emad separately to know the status of this. > > Best, > Franziskus > > > On Fri, 4 Sep 2020 at 13:23, Alexandre GOUAILLARD < > Alex.GOUAILLARD@cosmosoftware.io> wrote: > >> Hi franz., >> >> Thank you for your interest and the kind words. >> >> "Conferencing" is certainly a topic of interest, and i understand the >> focus of wire. SFrame can certainly be used in that context. >> >> However, there are other use cases than conferencing where media >> encryption is of interest, including but not limited to >> streaming/broadcasting and then of course all the hybrid use cases we start >> seeing emerging (watch parties, webinars, ....). >> >> We designed SFrame itself to refer ONLY to the media encryption part, and >> be as much as possible media transport agnostic, and use case/threat >> model/trust model agnostic, where the precedent attempt was extremely >> focussed on RTP-based conferencing. >> >> Eventually, each use case (e.g. conferencing) should have >> additional documents to come up to a full system whose properties could be >> verified, but we did not want to restrict the charter to a single use case. >> >> Right now, emad is working on the conferencing use case with sergio, and >> you might want to liaise with them on that specific topic. One document >> about how SFrame can be used with RTP, and, seprately, with MLS including >> the corresponding threat model is in progress. I think this is what you are >> looking for. >> >> In parallel, work is being done on application to SFrame for >> streaming/broadcasting and how it relates/overlaps with existing DRM >> solutions today in the bigger context. This will also hopefully have its >> own set of document. EVentually all would have the media encryption, >> SFrame, in common. >> >> Hope this helps. >> >> >> >> On Fri, Sep 4, 2020 at 6:23 PM Franziskus Kiefer < >> franziskuskiefer@gmail.com> wrote: >> >>> Hi all, >>> >>> First, thanks for working on this. >>> Wire is currently considering sframe for some use cases. >>> >>> Looking at the charter I noticed two things: >>> >>> The charter currently doesn't talk about authentication and to which >>> extent the WG wants to look at it. While authenticity might be implicit >>> through the used keys the sframe draft currently also uses signatures. >>> >>> I'm missing a statement about the process followed by the WG. End-to-end >>> encrypted conferencing is a relatively new topic without much research >>> around threat models. I therefore think that a process that validates the >>> threat model and the proposed solution is warranted. This might not have >>> the same extent as for TLS or MLS, but would still be good to have. >>> >>> Cheers, >>> Franziskus >>> -- >>> Sframe mailing list >>> Sframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/sframe >>> >> --000000000000536fc205ae7bebce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
But the charter can set out the process taken by the WG. And all us= e cases here should profit from this (i.e. making sure that the threat mode= ling and solution for each use case are vetted by other parties, in particu= lar academia).

I think our goal= s are aligned.
=C2=A0

> Right now, emad is working on the conferencing use cas= e with sergio, and you might want to liaise with them on that specific topic. One document about how SFrame can be used with RTP, and, seprately, with MLS=20 including the corresponding threat model is in progress. I think this is what you are looking for.

I currently only know a= bout https:/= /github.com/eomara/sframe. Is there any other draft in progress?

Yes. You might want to contact em= ad separately to know the status of this.
=C2=A0

Best,
Franz= iskus


On Fri, 4 Sep 2020 at 13:23, Alexandre GOUAILLARD <Alex.GO= UAILLARD@cosmosoftware.io> wrote:
Hi franz.,

Thank you for your interest and the = kind words.

"Conferencing" is certainly = a topic of interest, and i understand the focus of wire. SFrame can certain= ly be used in that context.

However, there are oth= er use cases than conferencing where media encryption is of interest, inclu= ding but not limited to streaming/broadcasting and then of course all the h= ybrid use cases we start seeing emerging (watch parties, webinars, ....).

We designed SFrame itself to refer ONLY to the medi= a encryption part, and be as much as possible media transport agnostic, and= use case/threat model/trust model agnostic, where the precedent attempt wa= s extremely focussed on RTP-based conferencing.

Ev= entually, each use case (e.g. conferencing) should have additional=C2=A0doc= uments to come up to a full system whose properties could be verified, but = we did not want to restrict the charter to a single use case.
Right now, emad is working on the conferencing use case with se= rgio, and you might want to liaise with them on that specific topic. One do= cument about how SFrame can be used with RTP, and, seprately, with MLS incl= uding the corresponding threat model is in progress. I think this is what y= ou are looking for.

In parallel, work is being don= e on application to SFrame for streaming/broadcasting=C2=A0and how it relat= es/overlaps with existing=C2=A0DRM solutions today in the bigger=C2=A0conte= xt. This will also hopefully have its own set of document. EVentually all w= ould have the media encryption, SFrame, in common.

Hope this helps.



On Fri, Sep 4, 2020 = at 6:23 PM Franziskus Kiefer <franziskuskiefer@gmail.com> wrote:
Hi all,

First= , thanks for working on this.
Wire is currently considering sfram= e for some use cases.

Looking at the charter I= noticed two things:

The charter currently doesn't talk a= bout authentication and to which extent the WG wants to look at it. While a= uthenticity might be implicit through the used keys the sframe draft curren= tly also uses signatures.

I'm missing a st= atement about the process followed by the WG. End-to-end encrypted conferen= cing is a relatively new topic without much research around threat models. = I therefore think that a process that validates the threat model and the pr= oposed solution is warranted. This might not have the same extent as for TL= S or MLS, but would still be good to have.

Cheers,=
Franziskus
--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--000000000000536fc205ae7bebce-- From nobody Mon Sep 7 09:42:16 2020 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 6CCC93A0814; Mon, 7 Sep 2020 09:42:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: sframe-chairs@ietf.org, sframe@ietf.org, dispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.15.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <159949693494.2875.16993532753477402380@ietfa.amsl.com> Date: Mon, 07 Sep 2020 09:42:15 -0700 Archived-At: Subject: [Sframe] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2020 16:42:15 -0000 Magnus Westerlund has entered the following ballot position for charter-ietf-sframe-00-00: Block 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-sframe/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- I know we have had discussion touching on this before. But post vacation and looking on this charter again I think we need to have some additional discussion of the goals and how the charter describes them in relation to encoder sub-streams and identification of what is encapsulated. In regards to the below: This working group will not specify the signaling required to configure SFrame encryption. In particular, considerations related to SIP or SDP are out of scope. This is because SFrame is intended to be applied as an additional layer on top of the base levels of protection that these protocols provide. This working group will, however, define how SFrame interacts with RTP (e.g., with regard to packetization, depacketization, and recovery algorithms) to ensure that it can be used in environments such as WebRTC. I think there exist a conflict in the above paragraph in relation to stated goals of the work. With the following earlier sentence: " It may also be desirable to encrypt units of intermediate size (e.g., H.264 NALUs or AV1 OBUs) to allow partial frames to be usable." in mind creating an RTP payload format that is capable of carrying SFRAMEs that contains these units will require some interaction with the signalling. Even without these sub-stream SFRAMEs there exist a description capability that needs to exist in an RTP payload format for the end-consumer to correctly be able to route the protected data after decapsulation and that the end-point having that capability. If the goal here when it comes to RTP is simply to be able to treat SFRAME as CODEC in WebRTC and thus use WebRTC InsertableStreams as a receiver of the decrypted media ADUs. Require the use of the WebRTC application to have a proprietary signalling to know what this ADU is and then route it to a media decoder? I can see that working in the WebRTC only context. However, I would prefer if some thought was spent on at least having a model for what information may be needed to be able to handle the media streams. Considering RFC 7656 (https://datatracker.ietf.org/doc/rfc7656/) and the work that was needed for us to up-level how RTP worked and even discuss this so that we understood each other. I think SFRAME needs to discuss how it is going to handle identification of the data encapsulated by SFRAMEs for media. A single media source can be encoded in multiple formats. Each format may produce one or more sub-streams of encoding for scalability or robustness and this needs to conveyed. So looking at the above challenges in the context of SFRAME over RTP. So a possibility here is to say that the SSRC represents either just a media source. The RTP payload format provides only fragmentation of the SFRAME across multiple RTP packets and the RTP timestamp can be used to indicate its belonging in the timeline of the encoding. That puts a lot of the identification on the SFRAME layer, but its minimizes the signalling interactions related to RTP. However it creates limitation about what the SFU can do, especially when it comes to repair. Switching can be done based on Frame-marker extension header. However, layer related loss detection becomes impossible without additional information, or use of multiple SSRCs. Thus, I think the charter as currently written are uncertain if it can be executed on with stated goals. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Information to form a unique nonce within the scope of the key Is this really "Information to form a" the best formulation. I am uncertain if the goal is to have a specification for how to generate unique Nonce values within the context of a particular key, or if it is related to which information sources that should be used when creating a nonce? From nobody Wed Sep 9 13:41:38 2020 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 887213A0DEA; Wed, 9 Sep 2020 13:41:36 -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: sframe-chairs@ietf.org, sframe@ietf.org, dispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.16.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <159968409648.6670.955964550557674225@ietfa.amsl.com> Date: Wed, 09 Sep 2020 13:41:36 -0700 Archived-At: Subject: [Sframe] Roman Danyliw's No Objection on charter-ietf-sframe-00-00: (with COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2020 20:41:37 -0000 Roman Danyliw has entered the following ballot position for charter-ietf-sframe-00-00: 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-sframe/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ** I share Éric Vyncke concerns with the bulleted list of what SFRAME encapsulation will provide. My recommendation would be to reframe this text around what security properties/assurances/services this encapsulation will provide (rather than a functional list). ** If configuring the security services is out of scope, where is it anticipated that this signalling protocol work would occur? From nobody Wed Sep 9 14:18:06 2020 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 3A72F3A0EAA; Wed, 9 Sep 2020 14:17:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline via Datatracker To: "The IESG" Cc: sframe-chairs@ietf.org, sframe@ietf.org, dispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.16.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <159968627781.11463.12811961039308421789@ietfa.amsl.com> Date: Wed, 09 Sep 2020 14:17:58 -0700 Archived-At: Subject: [Sframe] Erik Kline's No Objection on charter-ietf-sframe-00-00: (with COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2020 21:17:58 -0000 Erik Kline has entered the following ballot position for charter-ietf-sframe-00-00: 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-sframe/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [[ comments/questions ]] * Agree with "Information to form a unique nonce within the scope of the key" seeming a bit underdefined at the moment. * If conferencing migrates to carriage over QUIC, would that have any impact on/overlap with this work? From nobody Wed Sep 9 16:31:10 2020 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 F1C213A080C; Wed, 9 Sep 2020 16:31:01 -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: sframe-chairs@ietf.org, sframe@ietf.org, dispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.16.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <159969426190.10803.15690929161997611598@ietfa.amsl.com> Date: Wed, 09 Sep 2020 16:31:01 -0700 Archived-At: Subject: [Sframe] Benjamin Kaduk's No Objection on charter-ietf-sframe-00-00: (with COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2020 23:31:02 -0000 Benjamin Kaduk has entered the following ballot position for charter-ietf-sframe-00-00: 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-sframe/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Magnus's and Érics' Blocks. Some additional comments: Real-time conferencing sessions increasingly require end-to-end protections that prevent intermediary servers from decrypting real-time media. The PERC WG developed a “double encryption” scheme for end-to-end encryption that was deeply tied to SRTP as its underlying transport. This entanglement has prevented widespread deployment. I thought we were going to tweak this text (noting that RFC RFC 8723 is only a handful of months old). It might also be worth a note about the general expected shape of the key hierarchy (e.g., one key per sender vs. full mesh). * Selection among multiple encryption keys in use during a real-time session * Information to form a unique nonce within the scope of the key * Authenticated encryption using the selected key and nonce I assume that this means "assembling preexisting crypto building blocks", not "define new crypto". The transport-independence of this encapsulation means that it can be applied at a higher level than individual RTP payloads. For example, it may be desirable to encrypt whole frames that span multiple packets in order to amortize the overhead from framing and authentication tags. It may also be desirable to encrypt units of intermediate size (e.g., H.264 NALUs or AV1 OBUs) to allow partial frames to be usable. The working group will choose what levels of granularity are available and to what degree this can be configured. (Available as input to the WG of available from its output?) It is anticipated that several use cases of SFrame will involve its use with keys derived from the MLS group key exchange protocol. The working group will define a mechanism for doing SFrame encryption using keys from MLS, including, for example, the derivation of SFrame keys per MLS epoch and per sender. Will other sources of key material be considered? From nobody Thu Sep 10 04:48:40 2020 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 D2AA13A092E; Thu, 10 Sep 2020 04:48:34 -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: sframe-chairs@ietf.org, sframe@ietf.org, dispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.16.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <159973851434.24711.6050855169807417727@ietfa.amsl.com> Date: Thu, 10 Sep 2020 04:48:34 -0700 Archived-At: Subject: [Sframe] Robert Wilton's No Objection on charter-ietf-sframe-00-00: (with COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 11:48:35 -0000 Robert Wilton has entered the following ballot position for charter-ietf-sframe-00-00: 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-sframe/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This may come up in the context of the document reviews, but given the recent discussions on terminology we may want to proactively avoid use of the term 'nonce' in the WG charter. From nobody Thu Sep 10 06:41:44 2020 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 2CD393A0A36 for ; Thu, 10 Sep 2020 06:41:37 -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=unavailable 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 8e7UqoyH0Kin for ; Thu, 10 Sep 2020 06:41:35 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 849903A0A2D for ; Thu, 10 Sep 2020 06:41:35 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id p65so4845425qtd.2 for ; Thu, 10 Sep 2020 06:41:35 -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=KY2FWG7kdqga+OMvDhwCIEoStPaL7sOxC7JBQr5VHOg=; b=tq1B9n8ItcpjoxDYqbtnGqgzny9Yk70ojMjxwIGVmkqnOgw0XVoDzxkF/DRTXqAJGg NsDcQzeK9hYs0c4Npgo/r4+za76QRFkBCq+ezz+YfCq2aHWUNit7kqrDcNIOsYZD+9zo KMcqYktmK+MFOy3C8rNUNjtE1NtmrEoDO9EcbiSNtCgLgeYkccLHGTI1fTxnCWokexD9 gwbzQkL4nFLNwqchQ0J3mv/e14RO5QogbhKVgw/oOnNDm/RBmwoUjt3/NToHr5pysdB7 G/78dbpeW+bN+4P/XyKzwgPMPOJ7v+NtRLpTFTg9vmLc8hIzl7xouM/5TVOE/ZHTouJE CtBw== 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=KY2FWG7kdqga+OMvDhwCIEoStPaL7sOxC7JBQr5VHOg=; b=JN+gxI1hB5XOMtjq+pxG+D+J+UXQDKFMd2HNkGKU4z9sLbS8E8lohOkN9g8/MuVGF+ mJmbyh2OcV6W20Slc5AtZGon7XQwfrmj/pDd5OIpWpzM7IKzd0FwM/Gxck2Jpl+1Ncr5 /rAziaFOTuTl+xbshGw6a1AUHok0Gn4kOpfCD+/vQ5gewjfQPV9B8fFjxzERu5tow/Hd kRFqI2DXNhCrNQYyIUU9m9JKGOTQVG9wtKeOdfIHRsq/PE55lVwWIpLREiKV3K7eeIK5 2xnNhhWjo1pt/uqh0VVrRoOTqufid1oUPzrqqTfzWCnd6VVPjCMS8QRFewICLeCGShY2 Fu7A== X-Gm-Message-State: AOAM531G0btfz0Z9UxtQFQb75IpwzuECXzzn4i4HovhiP6Cgsco+0S0f R1GCpXWq0cxCPBzEcFVHPDejlwh54tAWko/T5424Vg== X-Google-Smtp-Source: ABdhPJyLjADAPdyslyBJ5d+uwypb4QgmytjBZu1vaILhX2ATYAjfHVyIH41zvPgvpx/eleH3Ttl4AFn56VrK8gHFDc4= X-Received: by 2002:ac8:1b92:: with SMTP id z18mr781016qtj.265.1599745294521; Thu, 10 Sep 2020 06:41:34 -0700 (PDT) MIME-Version: 1.0 References: <159968627781.11463.12811961039308421789@ietfa.amsl.com> In-Reply-To: <159968627781.11463.12811961039308421789@ietfa.amsl.com> From: Richard Barnes Date: Thu, 10 Sep 2020 09:41:17 -0400 Message-ID: To: Erik Kline Cc: The IESG , sframe-chairs@ietf.org, DISPATCH , sframe@ietf.org Content-Type: multipart/alternative; boundary="00000000000002eb2705aef5ba3a" Archived-At: Subject: Re: [Sframe] Erik Kline's No Objection on charter-ietf-sframe-00-00: (with COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 13:41:37 -0000 --00000000000002eb2705aef5ba3a Content-Type: text/plain; charset="UTF-8" Hi Erik: To you question about QUIC -- No impact. QUIC would provide the outer, "hop by hop" layer of protection, as SRTP would today. SFrame would still be needed for the E2E layer. On Wed, Sep 9, 2020 at 5:18 PM Erik Kline via Datatracker wrote: > Erik Kline has entered the following ballot position for > charter-ietf-sframe-00-00: 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.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-sframe/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > [[ comments/questions ]] > > * Agree with "Information to form a unique nonce within the scope of the > key" > seeming a bit underdefined at the moment. > > * If conferencing migrates to carriage over QUIC, would that have any > impact on/overlap with this work? > > > > -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --00000000000002eb2705aef5ba3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Erik: To you question about QUIC -- No impact.=C2=A0 QU= IC would provide the outer, "hop by hop" layer of protection, as = SRTP would today.=C2=A0 SFrame would still be needed for the E2E layer.
=

= On Wed, Sep 9, 2020 at 5:18 PM Erik Kline via Datatracker <noreply@ietf.org> wrote:
Erik Kline has entered the following= ballot position for
charter-ietf-sframe-00-00: 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.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-s= frame/



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

[[ comments/questions ]]

* Agree with "Information to form a unique nonce within the scope of t= he key"
=C2=A0 seeming a bit underdefined at the moment.

* If conferencing migrates to carriage over QUIC, would that have any
=C2=A0 impact on/overlap with this work?



--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--00000000000002eb2705aef5ba3a-- From nobody Thu Sep 10 06:43:55 2020 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 45BFE3A0A39 for ; Thu, 10 Sep 2020 06:43:54 -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 Ib--lvbQ4QXt for ; Thu, 10 Sep 2020 06:43:53 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 DEAB83A0A2D for ; Thu, 10 Sep 2020 06:43:52 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id w186so6079754qkd.1 for ; Thu, 10 Sep 2020 06:43:52 -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=IB7xXDM8hr63Q7z545YYfBbwqCjjqHfXpul4Pw+UtdQ=; b=fsb89ZGa7/MEsC2f1QhD0Bwj0iMTX2WFaajFs03XJGjC+n1sAXZP5Yy5OlXqPZjPw1 nJXwoKSqHGvbAHki6X6VHP94QO5zrL8gUPvG8oitDrYFYRuq4AP4BrxC0ujMNtOpUmZm 4gb9yHIgRdHHlKB10Ot/Saam8ChMfoo1d3HPfZXIBSrTJIDWNMUdAbjClXRH63N1uRVc qMKMgXVrhlDenPcIcv/cBtqC5Owv5DEbQsplML+ZMVxq+FZIDF04KHnrk+LtpFBUh5pZ M4PqQEpOKRznDJBlrNcLeF1icbvj2isCPKVixOnaNgdZtWEpM+onLL3Vd6mnlXz0itj6 Q9KA== 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=IB7xXDM8hr63Q7z545YYfBbwqCjjqHfXpul4Pw+UtdQ=; b=USzjjcWlGBLANdjI318efdP38Yzuv23xo7dUf3Y+uOUwebAh2IJbZORaTJSJi01uBt gw1RlXzxQG1Y39AMhomOOTjLNXs+JnQvSDlN4cN6il6WY5O/AhPrOLJfUcO4p1Hnel0C 3w6qBrlatwfRF2mOzo7BPouTYXJWma4L2YR/KVAd7GJuaSLIu07/ztPn5N32dddFPNDP +Hpt4jqCy6TyzovOmiaw55HVcfHiNjT84a8+LQS81PM2/UCbimh5SMXsc0flar7eSbJ7 wwqORx44qlnandRy9C1m/gZUOfvbhNqmn0M6rAIV8NnaF7apMp7baKJDOZQufokvbDg9 BTBg== X-Gm-Message-State: AOAM532lIOjkETLbNwYoeVF4ka7OjLOxKa5uMGcUL7ugikuvRX0mB2SL TKhNnFys8ncoDmIkVNB7LRHCHuNIL6aIinATRcaibA== X-Google-Smtp-Source: ABdhPJzoaPCXkW1bKJJqWQzFn887Bg76AxqtQz07ktxAKm4Wvy9gNxnGZ1wZDPsTaM7bEepDB6+bveBqLT8BCrRS14Y= X-Received: by 2002:a05:620a:1597:: with SMTP id d23mr7852975qkk.347.1599745431960; Thu, 10 Sep 2020 06:43:51 -0700 (PDT) MIME-Version: 1.0 References: <159968409648.6670.955964550557674225@ietfa.amsl.com> In-Reply-To: <159968409648.6670.955964550557674225@ietfa.amsl.com> From: Richard Barnes Date: Thu, 10 Sep 2020 09:43:34 -0400 Message-ID: To: Roman Danyliw Cc: The IESG , sframe-chairs@ietf.org, DISPATCH , sframe@ietf.org Content-Type: multipart/alternative; boundary="0000000000003413f305aef5c253" Archived-At: Subject: Re: [Sframe] Roman Danyliw's No Objection on charter-ietf-sframe-00-00: (with COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 13:43:54 -0000 --0000000000003413f305aef5c253 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Roman, The encapsulation provides exactly one service, authenticated encryption. (Symmetric encryption, if that needs clarifying.) So there's no question of configuring security services. I'll tighten things up to be clearer about this. --Richard On Wed, Sep 9, 2020 at 4:41 PM Roman Danyliw via Datatracker < noreply@ietf.org> wrote: > Roman Danyliw has entered the following ballot position for > charter-ietf-sframe-00-00: 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.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-sframe/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > ** I share =C3=89ric Vyncke concerns with the bulleted list of what SFRAM= E > encapsulation will provide. My recommendation would be to reframe this > text > around what security properties/assurances/services this encapsulation wi= ll > provide (rather than a functional list). > > ** If configuring the security services is out of scope, where is it > anticipated that this signalling protocol work would occur? > > > > -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --0000000000003413f305aef5c253 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Roman,

The encapsulation = provides exactly one service, authenticated encryption.=C2=A0 (Symmetric en= cryption, if that needs clarifying.)=C2=A0 So there's no question of co= nfiguring security services.=C2=A0 I'll tighten things up to be clearer= about this.

--Richard


On Wed, Sep 9, 2020 at 4:41 PM Roman Danyliw via Datatracker <noreply@ietf.org> wrote:
Roman Danyliw has entered t= he following ballot position for
charter-ietf-sframe-00-00: 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.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-s= frame/



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

** I share =C3=89ric Vyncke concerns with the bulleted list of what SFRAME<= br> encapsulation will provide.=C2=A0 My recommendation would be to reframe thi= s text
around what security properties/assurances/services this encapsulation will=
provide (rather than a functional list).

** If configuring the security services is out of scope, where is it
anticipated that this signalling protocol work would occur?



--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--0000000000003413f305aef5c253-- From nobody Thu Sep 10 06:57:04 2020 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 E5D263A0A79 for ; Thu, 10 Sep 2020 06:57:02 -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 wt0oJP_FiVmC for ; Thu, 10 Sep 2020 06:57:01 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 417E33A0A3E for ; Thu, 10 Sep 2020 06:57:01 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id p4so6129848qkf.0 for ; Thu, 10 Sep 2020 06:57:01 -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=d0PA05n2CZu95Ov7m2OhlIYUW1DbqbouFhzs0Trd1vg=; b=BWAaPiHjtc3/DxtbAx3GKZHY3o/2cbqDxhzOPqgzPG4FeJyR/zDM5k4x/uzONf8no+ rQ07CRPAZ2LT2GAyj8Auf6DDq9oQe42GBhzbkMbmRP+BTUnseT4u79Q41DplSXVOXRM0 ZD6ewJGX94zrbXGF8JHpJdB2jhk07LGiJXT7+MJCtqdgWTXuGOW00Tx5j8/3JDZuiyRR nldD04v8G8VoTl/EIsjaDdcjXigJoKnZEabd2yX25xl9AsuHn78b2V1e51BHDJTQay+c dBmi2cZ65qr/fvDIK46yDfjqgtVvJpCWg+uirXAHsl3GAAKb1I8wfquBGU0Q2xnZev5h fEiw== 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=d0PA05n2CZu95Ov7m2OhlIYUW1DbqbouFhzs0Trd1vg=; b=outtcscZ7/q1Iklk0TA3JF83J/whZZ/mUSTXHo/JhqW1NwIpyJOzBYmSqAXkHo0rkS lH5om3bS/6UEK9KTFgqMDsIBJtYThrpDi/n1yYhXxyVID08b1mKNS66ZC63iluMJYoQV oJjoL3+JO3O8cdnkmU9RzrqFC/ZZNpzthr8xP9mDfBy7I33edrQMQ/boVwrOEQKQmYCY 1nup2HlphGTuGdq9Hy9Lhp1EmrI7shutwg0UVEWGmTx9rIFGRmc7a9rBhKTVq4bgwIDO m/PUaUkN58phbhzpnQpj298ljPEC2OVR9hqhRMkVkfFNSDbvOvhLYIHh3yBgKRKbOTPf gHWw== X-Gm-Message-State: AOAM531TBxnyx3mu1lOBA4OJlUWDNTBmib6h//1FoEa1OmdzXrgDZ6Cg BHzmSmWIm1EkrtiaOHmLBBFURAsS3amg1ia6TIzn0w== X-Google-Smtp-Source: ABdhPJzJAYlLinhGJKmrIyZxmZ+U0ZvYARpH5+kSQKn7UAH7zdJ38+FZjObDaGLcRVByGDhdfjkmpsJcMzanW+GynhU= X-Received: by 2002:a37:d09:: with SMTP id 9mr8003521qkn.159.1599746220244; Thu, 10 Sep 2020 06:57:00 -0700 (PDT) MIME-Version: 1.0 References: <159969426190.10803.15690929161997611598@ietfa.amsl.com> In-Reply-To: <159969426190.10803.15690929161997611598@ietfa.amsl.com> From: Richard Barnes Date: Thu, 10 Sep 2020 09:56:42 -0400 Message-ID: To: Benjamin Kaduk Cc: The IESG , sframe-chairs@ietf.org, DISPATCH , sframe@ietf.org Content-Type: multipart/alternative; boundary="00000000000030674705aef5f13a" Archived-At: Subject: Re: [Sframe] Benjamin Kaduk's No Objection on charter-ietf-sframe-00-00: (with COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 13:57:03 -0000 --00000000000030674705aef5f13a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ben, See inline. On Wed, Sep 9, 2020 at 7:31 PM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > Real-time conferencing sessions increasingly require end-to-end > protections that prevent intermediary servers from decrypting > real-time media. > The PERC WG developed a =E2=80=9Cdouble encryption=E2=80=9D scheme fo= r end-to-end > encryption > that was deeply tied to SRTP as its underlying transport. This > entanglement > has prevented widespread deployment. > > I thought we were going to tweak this text (noting that RFC RFC 8723 is > only a > handful of months old). > Given the speed of the RFC process vs. the speed of deployment these days, successful things succeed before RFC. > It might also be worth a note about the general expected shape of the key > hierarchy (e.g., one key per sender vs. full mesh). > I don't think we have an expected shape. In practice, it will always be per-sender keys. But that's not an assumption we should bake in. If you want an IETF precedent, the right analogy would be something like CMS AuthEnvelopedData [https://tools.ietf.org/html/rfc5083]. Except that SFrame (a) wouldn't do the asymmetric-encrypt-the-key part, and (b) would optimize down the encoding to be suitable for real-time. > * Selection among multiple encryption keys in use during a real-time > session > * Information to form a unique nonce within the scope of the key > * Authenticated encryption using the selected key and nonce > > I assume that this means "assembling preexisting crypto building blocks", > not > "define new crypto". > Correct. It means "send the ciphertext". I think we can probably delete this bullet. > The transport-independence of this encapsulation means that it can be > applied > at a higher level than individual RTP payloads. For example, it may = be > desirable to encrypt whole frames that span multiple packets in order > to > amortize the overhead from framing and authentication tags. It may > also be > desirable to encrypt units of intermediate size (e.g., H.264 NALUs or > AV1 OBUs) > to allow partial frames to be usable. The working group will choose > what > levels of granularity are available and to what degree this can be > configured. > > (Available as input to the WG of available from its output?) > Available in the output of the WG. That is, there's a granularity configuration parameter that we might want in the protocol, and it's up to the WG to decide whether the parameter exists, and if so, what settings it has. It is anticipated that several use cases of SFrame will involve its use > with > keys derived from the MLS group key exchange protocol. The working > group will > define a mechanism for doing SFrame encryption using keys from MLS, > including, > for example, the derivation of SFrame keys per MLS epoch and per > sender. > > Will other sources of key material be considered? > Absolutely! The default case is manual / unspecified keying (again, just like with the CMS case above). This paragraph just says that *in addition to that*, the WG will specify how it works with MLS. --Richard > > > > -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --00000000000030674705aef5f13a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,

See= inline.

On Wed, Sep 9, 2020 at 7:31 PM Benjamin Kaduk via Datatra= cker <noreply@ietf.org> wrote= :
=C2=A0 =C2=A0 = Real-time conferencing sessions increasingly require end-to-end
=C2=A0 =C2=A0 protections that prevent intermediary servers from decrypting= real-time media.
=C2=A0 =C2=A0 The PERC WG developed a =E2=80=9Cdouble encryption=E2=80=9D s= cheme for end-to-end encryption
=C2=A0 =C2=A0 that was deeply tied to SRTP as its underlying transport.=C2= =A0 This entanglement
=C2=A0 =C2=A0 has prevented widespread deployment.

I thought we were going to tweak this text (noting that RFC RFC 8723 is onl= y a
handful of months old).

Given the speed= of the RFC process vs. the speed of deployment these days, successful thin= gs succeed before RFC.
=C2=A0
It might also be worth a note about the general expected shape of the key hierarchy (e.g., one key per sender vs. full mesh).
I don't think we have an expected shape.=C2=A0 In practice= , it will always be per-sender keys.=C2=A0 But that's not an assumption= we should bake in.

If you want an IETF preced= ent, the right analogy would be something like CMS AuthEnvelopedData [https://tools.ietf.org/html/rfc5= 083].=C2=A0 Except that SFrame (a) wouldn't do the asymmetric-encry= pt-the-key part, and (b) would optimize down the encoding to be suitable fo= r real-time.

=C2=A0
=C2=A0 =C2=A0 * Selection among multiple encryption keys in use during a re= al-time session
=C2=A0 =C2=A0 * Information to form a unique nonce within the scope of the = key
=C2=A0 =C2=A0 * Authenticated encryption using the selected key and nonce
I assume that this means "assembling preexisting crypto building block= s", not
"define new crypto".

Correct.= =C2=A0 It means "send the ciphertext".=C2=A0 I think we can proba= bly delete this bullet.

=C2=A0
=C2=A0 =C2=A0 The transport-independence of this encapsulation means that i= t can be applied
=C2=A0 =C2=A0 at a higher level than individual RTP payloads.=C2=A0 For exa= mple, it may be
=C2=A0 =C2=A0 desirable to encrypt whole frames that span multiple packets = in order to
=C2=A0 =C2=A0 amortize the overhead from framing and authentication tags.= =C2=A0 It may also be
=C2=A0 =C2=A0 desirable to encrypt units of intermediate size (e.g., H.264 = NALUs or AV1 OBUs)
=C2=A0 =C2=A0 to allow partial frames to be usable.=C2=A0 The working group= will choose what
=C2=A0 =C2=A0 levels of granularity are available and to what degree this c= an be configured.

(Available as input to the WG of available from its output?)

Available in the output of the WG.=C2=A0 That is, the= re's a granularity configuration parameter that we might want in the pr= otocol, and it's up to the WG to decide whether the parameter exists, a= nd if so, what settings it has.
=C2=A0

=C2=A0 =C2=A0 It is anticipated that several use cases of SFrame will invol= ve its use with
=C2=A0 =C2=A0 keys derived from the MLS group key exchange protocol.=C2=A0 = The working group will
=C2=A0 =C2=A0 define a mechanism for doing SFrame encryption using keys fro= m MLS, including,
=C2=A0 =C2=A0 for example, the derivation of SFrame keys per MLS epoch and = per sender.

Will other sources of key material be considered?

=
Absolutely!=C2=A0 The default case is manual / unspecified keyin= g (again, just like with the CMS case above).=C2=A0 This paragraph just say= s that *in addition to that*, the WG will specify how it works with MLS.

--Richard


= =C2=A0



--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--00000000000030674705aef5f13a-- From nobody Thu Sep 10 07:19:26 2020 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 1DEEB3A0B7E for ; Thu, 10 Sep 2020 07:19:20 -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=unavailable 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 6p5jdWx_QhbW for ; Thu, 10 Sep 2020 07:19:16 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 C65413A0B83 for ; Thu, 10 Sep 2020 07:19:16 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id o16so6161281qkj.10 for ; Thu, 10 Sep 2020 07:19:16 -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=OyQ8leW1TV6qpCS8oTNLkttLntIubi8YX0kdTowf6Zw=; b=wZp1s76RVSAOthlkNDELJKWmsniHzlJmUd1E7LZOjWrM3jRZdmAwxVPRpyImbzHXDN CmC6q7T+c95eaXJpE8KJQk0MVvS7wqq67DRgQn5XuAdwmgV5xZHsd79wq+r+3SRVEs8s H/fnC96Rpzg9ah7Jyc0ZsL5aCZ2XBr2LfU/UkN/oIdwas4zqwZhxEQh3DZehYA0A5yHl X7ARhMNTA2xgIapacdtLEmz67crsKIz6pEhv12m0SlhJ/LSEFdJ/L5sG9VKskVtxK4Xa 63Y67+Vy9NnHl+mgOjzew5zMK6QQaC9QeK6VR7u0kZsQAdYxRxMoZrpJQv7reMcCQn9L z57Q== 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=OyQ8leW1TV6qpCS8oTNLkttLntIubi8YX0kdTowf6Zw=; b=myr+1YyzPJ7FeXlbAnHhjYxKzQg3Z2uf0tT6GN2TgeLOFT7xnEFbwYJ3SzsH89fmtv P6NdrmidDGSZlWzJ3SZHDA26+FVsDgJBvXv6HCTt8iaX6agGs03vgYmw84eb9GYpTIrJ O37LKTFpZGjBhxpEU1PJf3XkYse19yUlir1yATHm5YUn7UvlSkkDbatT6lJux2UD2PO3 pDnqsIEqO7FbKwEUWklthiFLQNz+0fxT3qkCufx4CyMfPhF+U/rEwi9YA26Argl0eoBb 354rWT2jmbXabCygZl0CWBiWQA4hA63KzuFbdxtVczcDpcgICoXHvt5tC4XLiR4q7ST4 q+Jg== X-Gm-Message-State: AOAM532deFO+efSnBr0C68xXFHyRJeOYm0aXapiTepWUvz1/ObbQ8Tku q8AwIZGg3ZYuoALWL/wtT0PpCOaWXURqyDlVjELjuA== X-Google-Smtp-Source: ABdhPJxtAxe0KbIWdOZuDK+uW6wFxeaM3GlKU52H4GHaoP7m5FOYMhzcMzSWpllWUNZtx0d5QAc5hzqdaDs6ErG+fLQ= X-Received: by 2002:a05:620a:1266:: with SMTP id b6mr8243318qkl.371.1599747555777; Thu, 10 Sep 2020 07:19:15 -0700 (PDT) MIME-Version: 1.0 References: <159949693494.2875.16993532753477402380@ietfa.amsl.com> In-Reply-To: <159949693494.2875.16993532753477402380@ietfa.amsl.com> From: Richard Barnes Date: Thu, 10 Sep 2020 10:18:58 -0400 Message-ID: To: Magnus Westerlund Cc: The IESG , sframe-chairs@ietf.org, DISPATCH , sframe@ietf.org Content-Type: multipart/alternative; boundary="000000000000caf15005aef6406c" Archived-At: Subject: Re: [Sframe] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 14:19:20 -0000 --000000000000caf15005aef6406c Content-Type: text/plain; charset="UTF-8" Hi Magnus, I agree with Sergio here. The whole idea of SFrame is to have an encryption layer that doesn't care about any of the RTP nuances you talk about -- all of the details of how what decoder you send the plaintext to, substreams, etc. are handled by whatever RTP configuration mechanism you've set up. SFrame is just a translation layer between what you send on the wire and what you do all the other stuff with. Clearly, the nonce formation text is not clear. I've made some edits. https://docs.google.com/document/d/10rG8nAR0U6cBBPffzXnLaPPYL4uzxYViAvgiSezoa7o/edit?usp=sharing --Richard On Mon, Sep 7, 2020 at 12:42 PM Magnus Westerlund via Datatracker < noreply@ietf.org> wrote: > Magnus Westerlund has entered the following ballot position for > charter-ietf-sframe-00-00: Block > > 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.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-sframe/ > > > > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > I know we have had discussion touching on this before. But post vacation > and > looking on this charter again I think we need to have some additional > discussion of the goals and how the charter describes them in relation to > encoder sub-streams and identification of what is encapsulated. > > In regards to the below: > > This working group will not specify the signaling required to configure > SFrame > encryption. In particular, considerations related to SIP or SDP are out of > scope. This is because SFrame is intended to be applied as an additional > layer > on top of the base levels of protection that these protocols provide. This > working group will, however, define how SFrame interacts with RTP (e.g., > with > regard to packetization, depacketization, and recovery algorithms) to > ensure > that it can be used in environments such as WebRTC. > > I think there exist a conflict in the above paragraph in relation to stated > goals of the work. With the following earlier sentence: " It may also be > desirable to encrypt units of intermediate size (e.g., H.264 NALUs or AV1 > OBUs) > to allow partial frames to be usable." in mind creating an RTP payload > format > that is capable of carrying SFRAMEs that contains these units will require > some > interaction with the signalling. Even without these sub-stream SFRAMEs > there > exist a description capability that needs to exist in an RTP payload > format for > the end-consumer to correctly be able to route the protected data after > decapsulation and that the end-point having that capability. > > If the goal here when it comes to RTP is simply to be able to treat SFRAME > as > CODEC in WebRTC and thus use WebRTC InsertableStreams as a receiver of the > decrypted media ADUs. Require the use of the WebRTC application to have a > proprietary signalling to know what this ADU is and then route it to a > media > decoder? I can see that working in the WebRTC only context. However, I > would > prefer if some thought was spent on at least having a model for what > information may be needed to be able to handle the media streams. > Considering > RFC 7656 (https://datatracker.ietf.org/doc/rfc7656/) and the work that was > needed for us to up-level how RTP worked and even discuss this so that we > understood each other. I think SFRAME needs to discuss how it is going to > handle identification of the data encapsulated by SFRAMEs for media. A > single > media source can be encoded in multiple formats. Each format may produce > one or > more sub-streams of encoding for scalability or robustness and this needs > to > conveyed. > > So looking at the above challenges in the context of SFRAME over RTP. So a > possibility here is to say that the SSRC represents either just a media > source. > The RTP payload format provides only fragmentation of the SFRAME across > multiple RTP packets and the RTP timestamp can be used to indicate its > belonging in the timeline of the encoding. That puts a lot of the > identification on the SFRAME layer, but its minimizes the signalling > interactions related to RTP. However it creates limitation about what the > SFU > can do, especially when it comes to repair. Switching can be done based on > Frame-marker extension header. However, layer related loss detection > becomes > impossible without additional information, or use of multiple SSRCs. > > Thus, I think the charter as currently written are uncertain if it can be > executed on with stated goals. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > * Information to form a unique nonce within the scope of the key > > Is this really "Information to form a" the best formulation. I am > uncertain if > the goal is to have a specification for how to generate unique Nonce values > within the context of a particular key, or if it is related to which > information sources that should be used when creating a nonce? > > > > -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --000000000000caf15005aef6406c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Magnus,

I agree with Serg= io here.=C2=A0 The whole idea of SFrame is to have an encryption layer that= doesn't care about any of the RTP nuances you talk about -- all of the= details of how what decoder you send the plaintext to, substreams, etc. ar= e handled by whatever RTP configuration mechanism you've set up.=C2=A0 = SFrame is just a translation layer between what you send on the wire and wh= at you do all the other stuff with.

Clearly, the n= once formation text is not clear.=C2=A0 I've made some edits.


--Richard

<= div>

On Mon, Sep 7, 2020 at 12:42 PM Magnus Westerlund via Datatracker &= lt;noreply@ietf.org> wrote:
<= /div>
Magnus Westerlund ha= s entered the following ballot position for
charter-ietf-sframe-00-00: Block

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.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-s= frame/



----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

I know we have had discussion touching on this before. But post vacation an= d
looking on this charter again I think we need to have some additional
discussion of the goals and how the charter describes them in relation to encoder sub-streams and identification of what is encapsulated.

In regards to the below:

This working group will not specify the signaling required to configure SFr= ame
encryption.=C2=A0 In particular, considerations related to SIP or SDP are o= ut of
scope.=C2=A0 This is because SFrame is intended to be applied as an additio= nal layer
on top of the base levels of protection that these protocols provide.=C2=A0= This
working group will, however, define how SFrame interacts with RTP (e.g., wi= th
regard to packetization, depacketization, and recovery algorithms) to ensur= e
that it can be used in environments such as WebRTC.

I think there exist a conflict in the above paragraph in relation to stated=
goals of the work. With the following earlier sentence: " It may also = be
desirable to encrypt units of intermediate size (e.g., H.264 NALUs or AV1 O= BUs)
to allow partial frames to be usable." in mind creating an RTP payload= format
that is capable of carrying SFRAMEs that contains these units will require = some
interaction with the signalling. Even without these sub-stream SFRAMEs ther= e
exist a description capability that needs to exist in an RTP payload format= for
the end-consumer to correctly be able to route the protected data after
decapsulation and that the end-point having that capability.

If the goal here when it comes to RTP is simply to be able to treat SFRAME = as
CODEC in WebRTC and thus use WebRTC InsertableStreams as a receiver of the<= br> decrypted media ADUs. Require the use of the WebRTC application to have a proprietary signalling to know what this ADU is and then route it to a medi= a
decoder? I can see that working in the WebRTC only context. However, I woul= d
prefer if some thought was spent on at least having a model for what
information may be needed to be able to handle the media streams. Consideri= ng
RFC 7656 (https://datatracker.ietf.org/doc/rfc7656/) an= d the work that was
needed for us to up-level how RTP worked and even discuss this so that we understood each other. I think SFRAME needs to discuss how it is going to handle identification of the data encapsulated by SFRAMEs for media. A sing= le
media source can be encoded in multiple formats. Each format may produce on= e or
more sub-streams of encoding for scalability or robustness and this needs t= o
conveyed.

So looking at the above challenges in the context of SFRAME over RTP. So a<= br> possibility here is to say that the SSRC represents either just a media sou= rce.
The RTP payload format provides only fragmentation of the SFRAME across
multiple RTP packets and the RTP timestamp can be used to indicate its
belonging in the timeline of the encoding. That puts a lot of the
identification on the SFRAME layer, but its minimizes the signalling
interactions related to RTP. However it creates limitation about what the S= FU
can do, especially when it comes to repair. Switching can be done based on<= br> Frame-marker extension header. However, layer related loss detection become= s
impossible without additional information, or use of multiple SSRCs.

Thus, I think the charter as currently written are uncertain if it can be executed on with stated goals.


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


* Information to form a unique nonce within the scope of the key

Is this really "Information to form a" the best formulation. I am= uncertain if
the goal is to have a specification for how to generate unique Nonce values=
within the context of a particular key, or if it is related to which
information sources that should be used when creating a nonce?



--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--000000000000caf15005aef6406c-- From nobody Thu Sep 10 07:28:08 2020 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 59A743A0D7A for ; Thu, 10 Sep 2020 07:27:52 -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=unavailable 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 MHi0t6GpfCys for ; Thu, 10 Sep 2020 07:27:50 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 45FB33A0DDC for ; Thu, 10 Sep 2020 07:27:41 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id g3so4950365qtq.10 for ; Thu, 10 Sep 2020 07:27:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=1iiubohvZZgCoZZjDPCLNKlJI29PL4D8nMI9eCH9bdE=; b=MRlnsHP3x34newCm+2cBWCNet8cGH4b5/ZWFJBZhVmXFn76216pVfZiMbng2Wj4srC dcqk9LErtLz3EfB2iaTehuBh1NLTYhrbhqZgBVV5ecGhFhU0rOesWwdNzb/+CXdlIZHV JXv8jTwlTZK9e78Ox6VQSBq0KkFAZnC1uN/tAXh8R5mcUJGCAywJs42K15h9ysHuuIop oYLQQyqjq4w07bd79ouNeYaXoWfmY5/ZU+5xEhP9FH5BKAYvBNYRILHBAbuSdJv1NcDf Z7er8ncQxgAJeeBmwFveuWf9ig04959Okw1+LAyXsxYHSOtfq6OOPyn9aHBDaqfmP5/f vafQ== 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:cc; bh=1iiubohvZZgCoZZjDPCLNKlJI29PL4D8nMI9eCH9bdE=; b=g06hrm6//OW19HORZMCYnbNYV2Z5QTrNwljV9SDawkbvRToQbKUa+cA5s2dco7n+iN ljeaWY5oOacQbQdJdy9moMYYLVAtQuv69jS1aHBOC8nARy+6nahSl73vm+f0feKq5j7D aEqCAAJQ34x2tJZcoBn+hbReFIx5HnIxADs4CWGvFR7T3m/skZksh+aQfUvBXOVAj1Ge sZ8axztciJdRZfvHdSp/x2ghjIqsYi+k5aloy5HKK0GiUI7O19nwOSeXG4XoJjfX4Mg4 Qoo05aKKtMlMVQjs6VskzJzUbEqdwzpke3O9GdW0t7ho6Lm+C9FCOwXNGLt3rRfhUtVR zcRg== X-Gm-Message-State: AOAM5300pmKLqAEF+ZPBNGpOe0EO1+KBJq0r9d2Mobeme0Df34rqLeHU sD3kwPAbO2iVdMnbELcvetUgz9x5Pte2PTn1YWOxMw== X-Google-Smtp-Source: ABdhPJx9ADstUJzOpvES+0jyEHnh3Zo89j8LJ7WRQiwuF/DOBz/oBhRjiSmW1O91SOvmMithBYpe2FLmk0KuEfzLklo= X-Received: by 2002:ac8:4889:: with SMTP id i9mr8272382qtq.353.1599748060231; Thu, 10 Sep 2020 07:27:40 -0700 (PDT) MIME-Version: 1.0 From: Richard Barnes Date: Thu, 10 Sep 2020 10:27:22 -0400 Message-ID: To: "Eric Vyncke (evyncke)" Cc: DISPATCH , sframe@ietf.org, The IESG Content-Type: multipart/alternative; boundary="000000000000dc4db505aef65e9f" Archived-At: Subject: [Sframe] =?utf-8?q?=C3=89ric_Vyncke=27s_Block_on_charter-ietf-sf?= =?utf-8?q?rame-00-00?= X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 14:28:00 -0000 --000000000000dc4db505aef65e9f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi =C3=89ric, For some reason, your Block didn't get sent to the relevant mailing lists, so I'm crafting my own reply :) - 'Selection among multiple encryption keys' should there be a way to use > different encryption algorithm as well with the encapsulation (I noted th= at > this bullet is explicitly for inside a session)? > No. The assumption is that the algorithm is fixed for a given flow, but there may be multiple keys (e.g., for different senders), and of course, each encrypted unit needs a different nonce. We could add some text to clarify this if you think it's really necessary, but this seems like a finer level of granularity than is needed in a charter. > - like Magnus, I find "Information to form a unique nonce" pretty vague > and is it 'nonce' or more 'initialization vector' ? > I've revised to be clear that the encapsulation has a standard nonce formation algorithm, and the wire format provides the input to it. The word "nonce" is standard here (see https://tools.ietf.org/html/rfc5116#section-2.1) > - 'This working group will not specify the signaling required to configur= e > SFrame encryption", it is unclear to me whether the WG will specify a > control channel to negotiate keys and crypto algorithms as the current > sentence appears more generic configuration (e.g., supported crypto > algorithms) > No, the WG will not specify a control channel. That is something the application will have to provide. > - only one milestone ? There is nothing about the RTP mapping document > that is mentioned in the charter text > Yep. Just one thing, the encapsulation. The MLS mapping and RTP considerations should both be small enough to be sections in that document. --Richard --000000000000dc4db505aef65e9f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi =C3=89ric,

For some reaso= n, your Block didn't get sent to the relevant mailing lists, so I'm= crafting my own reply :)

- 'Selection among multiple encryption keys&#= 39; should there be a way to use different encryption algorithm as well wit= h the encapsulation (I noted that this bullet is explicitly for inside a se= ssion)?

No.=C2=A0 The assumption is tha= t the algorithm is fixed for a given flow, but there may be multiple keys (= e.g., for different senders), and of course, each encrypted unit needs a di= fferent nonce.=C2=A0 We could add some text to clarify this if you think it= 's really necessary, but this seems like a finer level of granularity t= han is needed in a charter.
=C2=A0
- like Magnus, I find "Information to for= m a unique nonce" pretty vague and is it 'nonce' or more '= initialization vector' ?

I've r= evised to be clear that the encapsulation has a standard nonce formation al= gorithm, and the wire format provides the input to it.=C2=A0 The word "= ;nonce" is standard here (see https://tools.ietf.org/html/rfc5116#section-2.1)
=C2=A0
- = 9;This working group will not specify the signaling required to configure S= Frame encryption", it is unclear to me whether the WG will specify a c= ontrol channel to negotiate keys and crypto algorithms as the current sente= nce appears more generic configuration (e.g., supported crypto algorithms)<= br>

No, the WG will not specify a control c= hannel.=C2=A0 That is something the application will have to provide.
=C2=A0
- on= ly one milestone ? There is nothing about the RTP mapping document that is = mentioned in the charter text

Yep.=C2= =A0 Just one thing, the encapsulation.=C2=A0 The MLS mapping and RTP consid= erations should both be small enough to be sections in that document.
=

--Richard


--000000000000dc4db505aef65e9f-- From nobody Thu Sep 10 07:41:09 2020 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 8BB7B3A0B97 for ; Thu, 10 Sep 2020 07:41:06 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 GpcKYIIpmHqS for ; Thu, 10 Sep 2020 07:41:03 -0700 (PDT) Received: from smtp001-out2.apm-internet.net (smtp001-out2.apm-internet.net [85.119.248.224]) (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 A7D503A0B91 for ; Thu, 10 Sep 2020 07:41:02 -0700 (PDT) Received: (qmail 22378 invoked from network); 10 Sep 2020 14:34:20 -0000 X-APM-Out-ID: 15997484602237 X-APM-Authkey: 255286/0(159927/0) 1135 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 10 Sep 2020 14:34:20 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 1504980B36; Thu, 10 Sep 2020 15:34:20 +0100 (BST) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id EnWgVsR8oElL; Thu, 10 Sep 2020 15:34:20 +0100 (BST) Received: from [192.168.0.102] (unknown [192.67.4.128]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id DFAE080B27; Thu, 10 Sep 2020 15:34:19 +0100 (BST) From: westhawk Message-Id: <44BA90CE-A41F-4FDA-A516-AAF03371D1A7@westhawk.co.uk> Content-Type: multipart/alternative; boundary="Apple-Mail=_21EFB90A-D401-4520-B341-2FE1C66695C8" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Thu, 10 Sep 2020 15:34:12 +0100 In-Reply-To: <159949693494.2875.16993532753477402380@ietfa.amsl.com> Cc: sframe-chairs@ietf.org, dispatch@ietf.org, sframe@ietf.org To: Magnus Westerlund References: <159949693494.2875.16993532753477402380@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Sframe] [dispatch] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 14:41:07 -0000 --Apple-Mail=_21EFB90A-D401-4520-B341-2FE1C66695C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 7 Sep 2020, at 17:42, Magnus Westerlund via Datatracker = wrote: >=20 > Even without these sub-stream SFRAMEs there > exist a description capability that needs to exist in an RTP payload = format for > the end-consumer to correctly be able to route the protected data = after > decapsulation and that the end-point having that capability. I think the assumption here (perhaps understated) is that both ends are = running compatible=20 sframe implementations. In webRTC this is done by them both loading the = same javascript or app version. In a more heterogeneous situation some signalling may be needed, but = that=E2=80=99s explicitly out of scope. > However it creates limitation about what the SFU > can do, especially when it comes to repair.=20 I think that=E2=80=99s an inevitable (and acceptable) consequence of e2e = encryption. T. --Apple-Mail=_21EFB90A-D401-4520-B341-2FE1C66695C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 7 Sep 2020, at 17:42, Magnus Westerlund via Datatracker = <noreply@ietf.org> wrote:

Even without these sub-stream SFRAMEs there
exist a description capability that needs to exist in an RTP = payload format for
the end-consumer to correctly be able = to route the protected data after
decapsulation and that = the end-point having that capability.

I think the assumption here (perhaps understated) = is that both ends are running compatible 
sframe = implementations. In webRTC this is done by them both loading the same = javascript or app version.
In a more heterogeneous situation = some signalling may be needed, but that=E2=80=99s explicitly out of = scope.


However it creates limitation about what the SFU
can do, especially when it comes = to repair. 

I think that=E2=80=99s an inevitable = (and acceptable) consequence of e2e encryption.

T.


= --Apple-Mail=_21EFB90A-D401-4520-B341-2FE1C66695C8-- From nobody Thu Sep 10 08:26:18 2020 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 C24183A0999; Thu, 10 Sep 2020 08:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, 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 ZEiBO50znSAn; Thu, 10 Sep 2020 08:26:11 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80070.outbound.protection.outlook.com [40.107.8.70]) (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 7C33B3A08B6; Thu, 10 Sep 2020 08:26:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RZz2lEhPbJ6SlCgT+2uLzRw5Qk1rGwPCUImnqaW8W39LJJEIQq98qMg367BiKDjT6EaTfA7QnTKUf1swQCaxDnEKOdojOKFGI9YoKrFS7m7JDswAyCjsqtf7mvfhwy+I6pGvCEL2Fdj1eTw6Pu3CXUvgaGqRTFCd1iYb8hHd97g5TGpLckgLq1x+OTSQ+YPig0+AUEhLWHkBTLv2tAo6wbokkm11Snr7OL12YpX9JJ9zBteNXfqTKdjDavH3A8L6noDt640IhlLuTMJSpmeDDRVFEyUPDdIMQCcDfLR2ODhrrxKj+NvIGh9RuNsUeLKpBN4jN5GcEpP3v3CfRww7fw== 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=niuLWHwKtMpM3sLLfcp+BFN+if1aC/U0/yDWTKxbgjY=; b=ElN5M3W3DcsYe6yQ+BJbDe1rFhjKJ6qj8eaeP7mIu2S+WrI8sF2nFeRmGlXJiw0P/QdjMLC4W2SOYAyLOOu1EYJwc2sWKe0piQs5bT5Dudj/agrUnatuJYdg4P5QJE5kCTRxZjs9e+ZbWOcR7b1KPzVKQPeCk8eVMny567aZQN8xigd6ZHcLfhS3+askrfcJ2UCO8yvgZyb7i7xBRGAYTWQi88BUMGRS4W6XW7LTynHzUfX7XUzC/edRFNVSyJqnckTkiG6109bwgK60P68/gTFbboVrIolMhrIjUuGORAEF4OUxko+2lIQqP2USFYW6V91cejPBBdPLDtpDua/iEg== 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=niuLWHwKtMpM3sLLfcp+BFN+if1aC/U0/yDWTKxbgjY=; b=KlyGHyQfIZWA+X4wysfBxatckanSsFu6qY/RaZ1ugXQh2si80VxvY3zwNQ85iILkkVQPJo9+gv0gQUu2EtQvCgSaVWPCyctmVcRprA6xs5NeGIGUBwHxeJNbFAAVFBDMbH/tZuRYXiOMYYHafVWo3wDlr8mJ5uLbfi5O22RJeWs= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR0702MB3627.eurprd07.prod.outlook.com (2603:10a6:7:84::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3370.7; Thu, 10 Sep 2020 15:26:06 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::b56f:9a8e:3399:aaa3]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::b56f:9a8e:3399:aaa3%7]) with mapi id 15.20.3370.016; Thu, 10 Sep 2020 15:26:06 +0000 From: Magnus Westerlund To: "rlb@ipv.sx" CC: "dispatch@ietf.org" , "iesg@ietf.org" , "sframe-chairs@ietf.org" , "sframe@ietf.org" Thread-Topic: [Sframe] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) Thread-Index: AQHWhTXfuLaYkFC4LEWqC8j5AGiLAKlh8DkAgAASwIA= Date: Thu, 10 Sep 2020 15:26:05 +0000 Message-ID: References: <159949693494.2875.16993532753477402380@ietfa.amsl.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2 authentication-results: ipv.sx; dkim=none (message not signed) header.d=none;ipv.sx; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [158.174.116.90] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e004ca50-fd3c-472d-ba7f-08d8559dd5ec x-ms-traffictypediagnostic: HE1PR0702MB3627: 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: JfwqsdllJhbDNMjz10pGJug+CozRkZmV4Yv19b9X7jqQ62OfU3nf5OpqMyGS/jMhcukD5uXSuV96m0Duf/HwSdTyDf0wzNKque3YWNvMa3jkNGUsbWpOY0/AtR6k/bTdo41yRlc4X+g50bdTXQFU3eV3WZ6RqpTYwyYuAuaJ47Uop224jhocphxwNqBJMWLJxN1BztRij6YElB+Zlh/ozxh0tyDN2bXds9NmoBGOAXpkMyZCueR78uVVXWAo4JidQbTuBWU9nE5rWFrlpBcx8oyl8RQHImh5J5fyHPr3nJMVDmF5lD8ZUqiaqf8+9Ko0Beoqm1uObTXVXsMeDcv+ojk7VOEuoeHvV79orLNgzD4oXDh8wDm338ws0JTDCrTRaLKoDZMbtnPXtBFiD/3iOg66mI9gr7KqcDkznqUTE1JfwpbTL0lAUe5Gz/4beWZDLNV/A1hrGFoZaB/DTlaYRg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(366004)(396003)(346002)(376002)(136003)(83380400001)(44832011)(316002)(6512007)(66446008)(64756008)(5660300002)(54906003)(6486002)(66556008)(76116006)(66476007)(2616005)(66946007)(36756003)(6506007)(86362001)(478600001)(2906002)(71200400001)(26005)(4326008)(6916009)(8936002)(186003)(966005)(8676002)(99106002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: t12j4ppxlFXrWUIeaO1XDYslFq8PPKo9m6hMMOJQMESrlGqei3kTdt40E4a9BCbe1HUID3ufgjA2mWYzzIcDdJQJgGTyxpkWmyJt6Pajb0xX6acasbircyr1iLe7GVqwlqm2su9kQKLT5WFtSd4f36naHnIDfctOvo3XfJXNc7k/ACmnhrLpa7BOy90ldoVWEM5QbZ20/W6Fiqw4OiL8sQ6LQu7b/yWzqFeelGU8J14RBcVZOzls4febBOX2nCsG5MG3GI0nVxo5SrBhc0MG4Xn79gzd2ho+qDJjY5jt9iQt3rYtqfhcdwlVyYCYmi7/DKoCU79f5v/i835o8KE9JQ0c4d+533sNo8mGNCS4aODAiFXPDa3JVXb4M566yzlDG9/vqhxtncaslahh1MSu2ykyo7Hs17iInJFDiWsfHAINFybgcDcGIf7Roma9VNwZgFSUZZfONxA6my3t/TMEJ0ASjiAhp0TjrnYYSsG9ILbC1LaaZAF1c8SIZeHbEy4xkPyYpRUJikcqktSCW4B4PHqRfDT25vk8paKUu0pyRDwS+ZWpCGONZUdgMdTTtXxwQQsLlp27zHibYqS/WPvfWQcM0TUdlrv1cahwXOcK3mS0iQ8gCSGK0WIyyaC5J7nZpPpjPqc770m4c6opkcgKOg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e004ca50-fd3c-472d-ba7f-08d8559dd5ec X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Sep 2020 15:26:05.9563 (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: dA+1K3DtM/S0B43B38bGOsAn4UxUx5gZtod4D6SvWY0WHRo23ZDHcfbVU9O8h/0sxYeiXoRvyKRsw0dozFKFf2gHBmrRBooHWiHfCtdx0aU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3627 Archived-At: Subject: Re: [Sframe] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 15:26:14 -0000 SGksDQoNCkkgaGF2ZSBub3cgcmVhZCBTZXJnaW8gYW5kIEJlcm5hcmRzIGRpc2N1c3Npb24gb24g dGhlIERpc3BhdGNoIGxpc3QuIEJ5IGRyb3BwaW5nDQppdCBkb3duIHRvIG9ubHkgZGlzcGF0Y2gg SSBtaXNzZWQgdGhhdCBkaXNjdXNzaW9uLiANCg0KT24gVGh1LCAyMDIwLTA5LTEwIGF0IDEwOjE4 IC0wNDAwLCBSaWNoYXJkIEJhcm5lcyB3cm90ZToNCj4gSGkgTWFnbnVzLA0KPiANCj4gSSBhZ3Jl ZSB3aXRoIFNlcmdpbyBoZXJlLiAgVGhlIHdob2xlIGlkZWEgb2YgU0ZyYW1lIGlzIHRvIGhhdmUg YW4gZW5jcnlwdGlvbg0KPiBsYXllciB0aGF0IGRvZXNuJ3QgY2FyZSBhYm91dCBhbnkgb2YgdGhl IFJUUCBudWFuY2VzIHlvdSB0YWxrIGFib3V0IC0tIGFsbCBvZg0KPiB0aGUgZGV0YWlscyBvZiBo b3cgd2hhdCBkZWNvZGVyIHlvdSBzZW5kIHRoZSBwbGFpbnRleHQgdG8sIHN1YnN0cmVhbXMsIGV0 Yy4NCj4gYXJlIGhhbmRsZWQgYnkgd2hhdGV2ZXIgUlRQIGNvbmZpZ3VyYXRpb24gbWVjaGFuaXNt IHlvdSd2ZSBzZXQgdXAuICBTRnJhbWUgaXMNCj4ganVzdCBhIHRyYW5zbGF0aW9uIGxheWVyIGJl dHdlZW4gd2hhdCB5b3Ugc2VuZCBvbiB0aGUgd2lyZSBhbmQgd2hhdCB5b3UgZG8gYWxsDQo+IHRo ZSBvdGhlciBzdHVmZiB3aXRoLg0KDQpMZXQgbWUgY2xhcmlmeSB3aGF0IEkgc2VlIGFzIHRoZSBp c3N1ZSB3aXRoIHRoZSBjaGFydGVyLiANCg0KU28gdGhlIHdob2xlIHBvaW50IGlzIHRvIGVuc3Vy ZSB0aGF0IHlvdSBjYW4gbW92ZSBTRlJBTUVzIHdpdGhvdXQgYW55IFJUUC4gVGh1cywNCndoYXQg SSB3YXMgdHJ5aW5nIHRvIGV4ZW1wbGlmeSB0aHJvdWdoIHRoZSBwcmV2aW91cyB3b3JrIGluIFJU UCBpcyB0byBiZSBhYmxlIHRvDQpkbyB0aGlzIFNGUkFNRSBkbyByZXF1aXJlIG1ldGEgZGF0YSB0 aGF0IGVuYWJsZXMgYSBoYW5kbGluZyBmdW5jdGlvbiB0byBzZXBlcmF0ZQ0KbGF5ZXJzIGFuZCBk ZXBlbmRlY2llcy4gVG8gc3VwcG9ydCB0aGlzIEkgdGhpbmsgeW91IGVuZCB1cCBpIHRoZSBuZWVk IGZvcg0KZXh0ZW5zaWJsZSBtZXRhIGRhdGEsIGRhdGEgdGhhdCBpcyB1bmVuY3J5cHRlZCBidXQg c3Ryb25nIGNvbnNpZGVyZCB0byBhdm9pZA0KaW5mb3JtYXRpb24gbGVha2FnZSBhbmQgaGF2ZSBn b29kIHNlY3VyaXR5IHByb3BlcnRpZXMuIFRha2luZyB0aGUgcmVndWxhciBSVFANCnBheWxvYWQg Zm9ybWF0IGhlYWRlcnMgc3RyYWlnaHQgbWF5IG5vdCBiZSB0aGUgYmVzdCBmaXQgZm9yIG1hbnkg Y29kZWNzLiAgSWYNCnRoYXQgaXMgZ29pbmcgdG8gYmUgZ2VuZXJpYyB5b3UgZW5kIHVwIGluIGEg bmFtaW5nIGFuZCBzdHJ1Y3V0cmUgZGlzY3Vzc2lvbiBsaWtlDQp3aGF0IGVuZGVkIHVwIGluIHRo ZSBUYXhvbm9teSBSRkMgYW5kIGxpa2UgZm9yIHRoZSBmcmFtZSBtYXJraW5nIFJUUCBoZWFkZXIN CmV4dGVuc2lvbi4NCg0KSG93ZXZlciwgdGhlIGlzc3VlIEkgcmVhbGx5IHJlYWN0ZWQgdG8gaGVy ZSBpcyB0aGUgZmFjdCB0aGF0IHRoZSBjaGFydGVyIGlzDQpzdGF0aW5nIHRoYXQgaXQgc2hvdWxk IGRvIGFuIFJUUCBwYXlsb2FkIGZvcm1hdC4gV2hlbiBkb2luZyBhbiBSVFAgcGF5bG9hZA0KZm9y bWF0IEkgdGhpbmsgaXQgaXMgcHJlLW1hdHVyZSBvZiB0aGUgY2hhcnRlciB0byBzYXkgdGhhdCB0 aGUgc2lnbmFsbGluZw0KcmVxdWlyZWQgZm9yIHRoZSBSVFAgcGF5bG9hZCBmb3JhbXQgaXMgb3V0 IG9mIHNjb3BlLiBJIHRoaW5rIHRoYXQgbmVlZHMgdG8gYmUNCnBhcnQgb2YgdGhlIHByb2Nlc3Mg dG8gZGlzY3VzcyBpbiB0aGUgUlRQIHBheWxvYWQgZm9ybWF0IGhvdyBhbiBSVFAgbWlkZGxlYm94 DQpjYW4gdXNlIHRoZSBwYXlsb2FkIGZvcm1hdCwgYW5kIGFueSBSVFAgZXh0ZW5zaW9uIGxpa2Ug ZnJhbWUgbWFya2luZyB0byBmaWd1cmUNCm91dCB3aGF0IHRvIGRvIHdoZW4gc3dpdGNoaW5nLiBU aGF0IFJUUCBwYXlsb2FkIGZvcm1hdCB3aWxsIHJlcXVpcmUgc29tZQ0KY29uZmlndXJhdGlvbiBj YXBhYmlsaXR5IHRvIGJlIGFibGUgdG8gd29yay4gDQoNClNvIHdoYXQgSSBhbSByZWFsbHkgYXNr aW5nIGZvciBpcyB0aGUgcmVtb3ZhYmxlIG9mIHRoZSByZXN0cmljdGlvbiB0aGF0IHByZXZlbnRz DQphIHJlZ3VsYXIgUlRQIHBheWxvYWQgZm9ybWF0IGRlc2lnbiB3b3JrLiBBbmQgc3RhdGluZyB0 aGF0IFNEUCBpcyBvdXQgb2Ygc2NvcGUNCmltcGxpZXMgdGhhdCB0byBtZSBpbiB0aGUgZGlyZWN0 IGNvbnRleHQgb2YgdGhlIHBheWxvYWQgZm9ybWF0LiANCg0KPiANCg0KaHR0cHM6Ly9kb2NzLmdv b2dsZS5jb20vZG9jdW1lbnQvZC8xMHJHOG5BUjBVNmNCQlBmZnpYbkxhUFBZTDR1enhZVmlBdmdp U2V6b2E3by9lZGl0P3VzcD1zaGFyaW5nDQo+IA0KDQpJIHRoaW5rIHRoZSBlZGl0cyBhcmUgYW4g aW1wcm92ZW1lbnQgc29sdmluZyBzZXZlcmFsIHVuY2xhcml0aWVzIGFyb3VuZCB0aGUNCm90aGVy IGlzc3VlcyBJIHJhaXNlZC4NCg0KTWF5YmUgb25lIHdheSBmb3J3YXJkIGlzIHRvIGJyZWFrIHRo ZSBwYXJhZ3JhcGggdGFsa2luZyBhYm91dCBzaWduYWxsaW5nIGFuZCBSVFANCnBheWxvYWQgZm9y bWF0IGludG8gdHdvIGRpZmZlcmVudCBwYXJhZ3JhcGguIFdoZXJlIHRoZSBSVFAgcGF5bG9hZCBm b3JtYXQgbmVlZA0KZm9yIHNpZ25hbGxpbmcgaXMgbm90IGFzc29jaWF0ZWQgd2l0aCB0aGUgaGln aGVyIGxldmVsIG5lZWQgZm9yIFNGUkFNRQ0Kc2lnbmFsbGluZyBvdmVyIGZvciBleGFtcGxlIGEg U0lQIHN5c3RlbS4gV2hpY2ggSSBhbSBmaW5lIHdpdGggZXhjbHVkaW5nDQpleHBsaWNpdGx5LiAN Cg0KU28ganVzdCB0YWxraW5nIGFib3V0IHRoZSBSVFAgUGF5bG9hZCBmb3JtYXQuIEkgdGhpbmsg dGhpcyBkbyBuZWVkIGEgbW9kZWwgZm9yDQpob3cgYW4gUlRQIFNGVSBpcyBnb2luZyB0byBiZSBh YmxlIHRvIGRvIHN3aXRjaGluZyBvbiBpdC4gU2hvdWxkbid0IHRoYXQgYmUgaW4NCnNjb3BlPyAN Cg0KQ2hlZXJzDQoNCk1hZ251cyBXZXN0ZXJsdW5kIA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCk5ldHdv cmtzLCBFcmljc3NvbiBSZXNlYXJjaA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRXJpY3Nzb24gQUIgICAgICAg ICAgICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQpUb3JzaGFtbnNnYXRhbiAyMyAgICAg ICAgICAgfCBNb2JpbGUgKzQ2IDczIDA5NDkwNzkNClNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRl biB8IG1haWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQoNCg0K From nobody Thu Sep 10 19:25:40 2020 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 207703A1330 for ; Thu, 10 Sep 2020 19:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.846 X-Spam-Level: X-Spam-Status: No, score=-2.846 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cosmosoftware-io.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 eGUoOI8iCMs6 for ; Thu, 10 Sep 2020 19:25:26 -0700 (PDT) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 703453A1355 for ; Thu, 10 Sep 2020 19:25:25 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id y15so3291847wmi.0 for ; Thu, 10 Sep 2020 19:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cosmosoftware-io.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=srbRRVxtQzsimE1XHHXoJ2QEvgiE6vctcJ9ba/k7B6k=; b=Bc+7YyOZtnfj0JiQHGyKuPD1ElRPso/es3JsW7rBMA2uNtPD1+a8ZD735U/mqd11dJ EOp53zAmd2ESGI5le6c1mKiFsUjtaS4unj7AeKml9aB+Popf4sARg46Q2rax/NtdxtPE HEvO5q3ZPyE6K+N6OzGfSFdnCiIKSeuDArQaqnzcuy04sKT3dlk1hUpMH5oRvWozFk3J 9+IUEyf6qvlDZq+o/8wa6RryF+OTGxtxhbWS928HKnzxnDbPlLgYMOVzENG7dLogLuCH 9d1hyf7h9LFJXUHqA7NGpL0Z+FZnTqMF/FNacMGH+U8TRw1syxmw8lp+XscNP8B1Tzvn 7X4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=srbRRVxtQzsimE1XHHXoJ2QEvgiE6vctcJ9ba/k7B6k=; b=jVWy5xiFnrJwsJM+D6fIPCVYwTmyWbD86eq4SPK5hcudtW9c0AWU9IAd2WInUot8UA u18eAThBhQXIgFxpdh+1NNq/nw31lQtUUTiHC1SZlwXXMXWfk3QJgPo7U1rWgOj1bFAC bHjDaMt1YGlq/JU0s2hyA3z+z9Kxeqqktz7oDSy5dhnjCq7/RKfaBF8L+2J9JrwW827A ZfXqc4Dw76DPg1dFxrLdoYaxZyYiPsItOilVtSKLPSqMsvvTADUiuaP6BzkM6vRNCsRM ksJqto6M/vkhTy9ZNnI6bBSbwEQ+a4y4u09U+JW+CPpLHSEb6iwbP/P2f332pvCfBydK XP+A== X-Gm-Message-State: AOAM533iHk9+LDK/2q19ZX/4XCtSBikEF3zorGAD8/fJUH9Us0wIgl0x CcV5DmwMFqQa0+x4qXddTkR+qjfOXwJkDQ== X-Google-Smtp-Source: ABdhPJw+d4QhaGn9o6uzfyfP+lUkTiUTb+3LTGUrmfePECKf0nDUGgywyWNnJdWfPBSTrzUpqTRFzA== X-Received: by 2002:a1c:4c05:: with SMTP id z5mr2655802wmf.47.1599791123629; Thu, 10 Sep 2020 19:25:23 -0700 (PDT) Received: from [192.168.0.11] (79.108.125.160.dyn.user.ono.com. [79.108.125.160]) by smtp.gmail.com with ESMTPSA id h8sm1393871wrw.68.2020.09.10.19.25.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2020 19:25:23 -0700 (PDT) To: Magnus Westerlund , "rlb@ipv.sx" Cc: "sframe-chairs@ietf.org" , "dispatch@ietf.org" , "iesg@ietf.org" , "sframe@ietf.org" References: <159949693494.2875.16993532753477402380@ietfa.amsl.com> From: Sergio Garcia Murillo Message-ID: Date: Fri, 11 Sep 2020 04:25:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Sframe] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2020 02:25:39 -0000 On 10/09/2020 17:26, Magnus Westerlund wrote: > [...] However, the issue I really reacted to here is the fact that the charter is > stating that it should do an RTP payload format. When doing an RTP payload > format I think it is pre-mature of the charter to say that the signalling > required for the RTP payload foramt is out of scope. I think that needs to be > part of the process to discuss in the RTP payload format how an RTP middlebox > can use the payload format, and any RTP extension like frame marking to figure > out what to do when switching. That RTP payload format will require some > configuration capability to be able to work. > > So what I am really asking for is the removable of the restriction that prevents > a regular RTP payload format design work. And stating that SDP is out of scope > implies that to me in the direct context of the payload format. I agree. As I read the charter, SDP is out of the scope for negotiating/signaling the usage of SFrame and the parameters that may be used for encryption/decryption. However, if the encrypted output is going to be transmitted over RTP using a new packetization format, we need to address how to negotiate that in the SDP. Note that this new packetization format will not only be alid for transporting encrypted frames (SFrame or not) but even any other audio/video frames. > [...] > Maybe one way forward is to break the paragraph talking about signalling and RTP > payload format into two different paragraph. Where the RTP payload format need > for signalling is not associated with the higher level need for SFRAME > signalling over for example a SIP system. Which I am fine with excluding > explicitly. > > So just talking about the RTP Payload format. I think this do need a model for > how an RTP SFU is going to be able to do switching on it. Shouldn't that be in > scope? Note that the RTP payload format may not be the one providing the switching information for an SFU. It is much cleaner to carry that information in a new (hop-by-hop encrypted) header extension so the payload does not need to be parser by the SFU at all, so the packetization can be "payload-agnostic". Best regards Sergio From nobody Fri Sep 11 00:40:12 2020 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 6A9893A0A16; Fri, 11 Sep 2020 00:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, 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 KqpeXzCb9Mai; Fri, 11 Sep 2020 00:40:09 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60053.outbound.protection.outlook.com [40.107.6.53]) (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 5AC403A0A13; Fri, 11 Sep 2020 00:40:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ETKhhljmOQv3bZdddXEZ91hjv3pcJDI+DZUXL64HP40q35UtG4C0Ecp20HL5icU32g4XbQxYqI25UNiQisbJJRtU7TuNnw0Lj4wG8y04irNp+M2UeDdRP1ByN3A7pTe7bprhvr1I1Y288NYk7EIzOSar0nmZUUcVd7hQ3AaA974JjgcUyqSYNlWGkJ4TjvvZzk5xCGNk1mbqx3EFINDezNNBr+samN6go3lmaAyDcN4+ydvbITdZCuDJQkcUT6QTu4xfm7PZmxQiMJ+fiK7+tdwKvcnMOtmfKqydmEJBcxRvELQm2LnUQC11bEQOTGAcn1kv8ki/dKLveoFdVBHAnw== 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=KM386ZxFTWPB1cXpejO0ILc2YlDpUN972pCvgCf8SFQ=; b=doYtmxlEk2XS+1yLc24yjHjRo8QCfKXeEInN01GplF/g1G1Q4m9MxSA6T5kZp/0pGEqWDPX2WdF+po+4V2FxvShr8dgVPNrX6OiI6hyxE80jfQ4jFLUe0xt0zj3lNisUKm1FLXtDxwtCu6cLFJoWiHfBo6BbEVRnVr0ZYBmx22qq5aNV2MmImskwuz3hZt0u4LGN6Jq4lyhliSPYG38q9FDfU6uja52beXy5d4TN2UEo6SMJ3XOCdlO4RMSKqOIllo4vgqAHM+s50FDyr1YU0lKbxnwxImS8i4XUiGhJbbDpCfM/U2Ao6Ixwyp22C5CcmeK4TrrszEw6alGQZipDFw== 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=KM386ZxFTWPB1cXpejO0ILc2YlDpUN972pCvgCf8SFQ=; b=HhqMFOokCUTNzXVPQRNi+k3JXb08H7RjfzxTa36FEJiIk6vHDonrLv/gx1I494hEA4REn+HrXblBdn6kISPdUtCOandDZC63/+J8h2E4X2PtzPVNcyrPJCbIt2Kjky1gEz1Xzme5GWQ73SGkhRTPszvh2MgUUbPK2nAHZYlVeJI= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR07MB4444.eurprd07.prod.outlook.com (2603:10a6:7:a0::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.4; Fri, 11 Sep 2020 07:39:34 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::b56f:9a8e:3399:aaa3]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::b56f:9a8e:3399:aaa3%7]) with mapi id 15.20.3370.016; Fri, 11 Sep 2020 07:39:34 +0000 From: Magnus Westerlund To: "sergio.garcia.murillo@cosmosoftware.io" , "rlb@ipv.sx" CC: "dispatch@ietf.org" , "iesg@ietf.org" , "sframe-chairs@ietf.org" , "sframe@ietf.org" Thread-Topic: [Sframe] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) Thread-Index: AQHWhTXfuLaYkFC4LEWqC8j5AGiLAKlh8DkAgAASwICAALgzgIAAV8mA Date: Fri, 11 Sep 2020 07:39:34 +0000 Message-ID: <5c6c96621b29ebf4b1f84e53ae3a414c9d0ec3a5.camel@ericsson.com> References: <159949693494.2875.16993532753477402380@ietfa.amsl.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2 authentication-results: cosmosoftware.io; dkim=none (message not signed) header.d=none;cosmosoftware.io; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [158.174.116.90] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 01f90f7b-35a8-4eb7-abff-08d85625d45a x-ms-traffictypediagnostic: HE1PR07MB4444: 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: IUPqbMFE0sOFI7YY/K9cVyKYFp+oPQvlnm5u9Jy92Rj+IrYn6GuMMN8cqmZkN5cpmoX14HwaHpCxRRV5sjiJu7+cJUWPxBQJicIpuEzI9sL6Ej76F2E6nc8j/naG4iF6TZG/fbDUa6dGD0mgF6SS09zBSYGfUWUU2i/uT/fXUT1KjYyn2PPD63zg6OlhTPJacQy1Vxk6q62zSr0QUxk7OABDNc6/3vsEVIa/rmjz+sq17CTzfIV2psACGZFGFAfjsV6T7T9YmEbImrBE2a9+8lxXp7xEQe9ocRNpCl2C1AnEuPrumU3qYAnt6rpxi5y1ZiXCb0AVBykurWXEbzdfNuIJejJBlq5FfYH6JY0R3ycso/bQViJr6SF1swshz1TK x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39860400002)(136003)(346002)(396003)(376002)(186003)(5660300002)(6512007)(44832011)(8676002)(6506007)(110136005)(26005)(478600001)(53546011)(2616005)(66446008)(66476007)(2906002)(86362001)(36756003)(316002)(76116006)(66946007)(4326008)(71200400001)(66556008)(8936002)(54906003)(6486002)(64756008)(99106002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: cUT8ajuzvFobvnMJGFWE2KQwPFcOVrIb/jaL/fL0F4t2y4xi6nKbDKqm2MNlSAsBJSaRdLn+zSHsl79dYOgDLbYLhEow+mDb179Uwy4kZHZ8RB5gdqKsHOgiUsJYFBR6pJjoThLebJJcfwqf00KK/rk+NO0xpZU2G6klGCiBCvN4RfNPRvdCGlKxEOoeQUkIuKSt1tptnWf6M73omjc3xzNHScx9aUjbu3kpyWWhA797HmjU2VCqm+LbDDSkj4cPPXJhCIql/509Th8ivSSoCRxLSGDpxmfnDFnyYVPQioVJFd7JfcTCVI2PYLcDqtoa8BiJ68JTVrdMvWt3UKOG3hD2t3BkcDLLScJZScK4Y7aJfb9P+SFlzuHPvTiu1W8rTgxaZZOC04HcxWjD1ccKX3D1PyKyCRT+UP/9omD1Dz5LC4uafqMUgYTP1vDtmbnwpQBdiFiBzSCJNQujoi9xboRyKJv7b1bEiH3OoSNKdJ+yxaZApfACBhxd9jXxAaHUR837ITmrKRAOPrBCIvdPgFwdvwg0ij1fjB8FjIFU3cX3fknF0hnlyh9tq9xiajZm+uHeVm7c6BIDkz9VtSBiNMy/uyxm3nkk1UKgaO47kWXhx0jI6Vu8jjvVoTsuL5xsrWGx3D/0NJ6IYNtF2UndBw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 01f90f7b-35a8-4eb7-abff-08d85625d45a X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2020 07:39:34.8666 (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: py9ekZGDQaR0ekT69dYEN2IfyCya7Ry2kwZS3nh8+06MhYu9vz56QpdeAcryUZhURSmempVhXDkK2/euxn+PVbIsBB+prfn8IvVr2+ktZdQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4444 Archived-At: Subject: Re: [Sframe] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2020 07:40:11 -0000 SGksDQoNCkkgdGhpbmsgd2UgYXJlIG1ha2luZyBnb29kIHByb2dyZXNzIGhlcmUuIA0KDQpPbiBG cmksIDIwMjAtMDktMTEgYXQgMDQ6MjUgKzAyMDAsIFNlcmdpbyBHYXJjaWEgTXVyaWxsbyB3cm90 ZToNCj4gT24gMTAvMDkvMjAyMCAxNzoyNiwgTWFnbnVzIFdlc3Rlcmx1bmQgd3JvdGU6DQo+IA0K PiA+IFsuLi5dIEhvd2V2ZXIsIHRoZSBpc3N1ZSBJIHJlYWxseSByZWFjdGVkIHRvIGhlcmUgaXMg dGhlIGZhY3QgdGhhdCB0aGUNCj4gPiBjaGFydGVyIGlzDQo+ID4gc3RhdGluZyB0aGF0IGl0IHNo b3VsZCBkbyBhbiBSVFAgcGF5bG9hZCBmb3JtYXQuIFdoZW4gZG9pbmcgYW4gUlRQIHBheWxvYWQN Cj4gPiBmb3JtYXQgSSB0aGluayBpdCBpcyBwcmUtbWF0dXJlIG9mIHRoZSBjaGFydGVyIHRvIHNh eSB0aGF0IHRoZSBzaWduYWxsaW5nDQo+ID4gcmVxdWlyZWQgZm9yIHRoZSBSVFAgcGF5bG9hZCBm b3JhbXQgaXMgb3V0IG9mIHNjb3BlLiBJIHRoaW5rIHRoYXQgbmVlZHMgdG8NCj4gPiBiZQ0KPiA+ IHBhcnQgb2YgdGhlIHByb2Nlc3MgdG8gZGlzY3VzcyBpbiB0aGUgUlRQIHBheWxvYWQgZm9ybWF0 IGhvdyBhbiBSVFANCj4gPiBtaWRkbGVib3gNCj4gPiBjYW4gdXNlIHRoZSBwYXlsb2FkIGZvcm1h dCwgYW5kIGFueSBSVFAgZXh0ZW5zaW9uIGxpa2UgZnJhbWUgbWFya2luZyB0bw0KPiA+IGZpZ3Vy ZQ0KPiA+IG91dCB3aGF0IHRvIGRvIHdoZW4gc3dpdGNoaW5nLiBUaGF0IFJUUCBwYXlsb2FkIGZv cm1hdCB3aWxsIHJlcXVpcmUgc29tZQ0KPiA+IGNvbmZpZ3VyYXRpb24gY2FwYWJpbGl0eSB0byBi ZSBhYmxlIHRvIHdvcmsuDQo+ID4gDQo+ID4gU28gd2hhdCBJIGFtIHJlYWxseSBhc2tpbmcgZm9y IGlzIHRoZSByZW1vdmFibGUgb2YgdGhlIHJlc3RyaWN0aW9uIHRoYXQNCj4gPiBwcmV2ZW50cw0K PiA+IGEgcmVndWxhciBSVFAgcGF5bG9hZCBmb3JtYXQgZGVzaWduIHdvcmsuIEFuZCBzdGF0aW5n IHRoYXQgU0RQIGlzIG91dCBvZg0KPiA+IHNjb3BlDQo+ID4gaW1wbGllcyB0aGF0IHRvIG1lIGlu IHRoZSBkaXJlY3QgY29udGV4dCBvZiB0aGUgcGF5bG9hZCBmb3JtYXQuDQo+IA0KPiANCj4gSSBh Z3JlZS4gQXMgSSByZWFkIHRoZSBjaGFydGVyLCBTRFAgaXMgb3V0IG9mIHRoZSBzY29wZSBmb3Ig DQo+IG5lZ290aWF0aW5nL3NpZ25hbGluZyB0aGUgdXNhZ2Ugb2YgU0ZyYW1lIGFuZCB0aGUgcGFy YW1ldGVycyB0aGF0IG1heSBiZSANCj4gdXNlZCBmb3IgZW5jcnlwdGlvbi9kZWNyeXB0aW9uLg0K DQpUaGUgc2lnbmFsbGluZyBmb3Igd2hhdCBpcyBpbiB0aGUgU0ZSQU1FIGlzIG91dCBvZiBzY29w ZSBhbHNvLiANCg0KU28gZG8gSSBhc3N1bWUgY29ycmVjdGx5IHRoYXQgdGhlIGlkZWEgaXMgdGhh dCB0aGUgYXBwbGljYXRpb24gbGF5ZXIgdXNpbmcNClNGUkFNRSBpZiBpdCBoYXZlcyBtdWx0aXBs ZSBpbmRlcGVuZGVudCBvciBzZXRzIG9mIGRlcGVuZGVudCBzdHJlYW1zIHRoZXJlIHdpbGwNCmJl IG5vIHN1cHBvcnQgZm9yIHRoYXQgYXNwZWN0IGluIFNGUkFNRSBsYXllcj8gSW5zdGVhZCBpdCBp cyB1cCB0byB0aGUNCmFwcGxpY2F0aW9uIHRvIHB1dCBzdWNoIGluZm9ybWF0aW9uIHRvIGVpdGhl ciBwdXQgaXQgaW5zaWRlIHRoZSBlbmNhcHN1YWx0ZWQNCnBhcnQgb2YgdGhlIFNGUkFNRSBvciBt YXAgaXQgdG8gdGhlIGxvd2VyIHRyYW5zcG9ydCBsYXllciwgbGlrZSB0byBSVFAgU1NSQ3MgYW5k DQpleHRlbnNpb24gaW5mb3JtYXRpb24uIA0KDQo+IA0KPiBIb3dldmVyLCBpZiB0aGUgZW5jcnlw dGVkIG91dHB1dCBpcyBnb2luZyB0byBiZSB0cmFuc21pdHRlZCBvdmVyIFJUUCANCj4gdXNpbmcg YSBuZXcgcGFja2V0aXphdGlvbiBmb3JtYXQsIHdlIG5lZWQgdG8gYWRkcmVzcyBob3cgdG8gbmVn b3RpYXRlIA0KPiB0aGF0IGluIHRoZSBTRFAuDQoNCkdvb2QNCg0KPiBOb3RlIHRoYXQgdGhpcyBu ZXcgcGFja2V0aXphdGlvbiBmb3JtYXQgd2lsbCBub3Qgb25seSBiZSBhbGlkIGZvciANCj4gdHJh bnNwb3J0aW5nIGVuY3J5cHRlZCBmcmFtZXMgKFNGcmFtZSBvciBub3QpIGJ1dCBldmVuIGFueSBv dGhlciANCj4gYXVkaW8vdmlkZW8gZnJhbWVzLg0KDQpJIHVuZGVyc3RhbmQgdGhlIHBvdGVudGlh bCBleGlzdHMuIEhvd2V2ZXIsIHRoZSByZWNvbW1lbmRhdGlvbiBmb3IgUlRQIGhhcyBiZWVuDQp0 byB0cnkgdG8gY29uc2lkZXIgQXBwbGljYXRpb24gTGV2ZWwgRnJhbWluZy4gSW4gdGhlIGNhc2Ug b2YgU0ZSQU1FIHRoYXQNCmNvbnNpZGVyYXRpb24gbW92ZXMgdXAgYWJvdmUgU0ZSQU1FIGluIHRo ZSBjaG9pY2Ugb2YgaG93IGRhdGEgaXMgc3BsaXQgaW50bw0KU0ZSQU1Fcy4gSG93ZXZlciwgaGF2 aW5nIGFuIFJUUCBwYXlsYW9kIGZvcm1hdCBmb3IgU0ZSQU1FLCB0aGVuIHRoYXQgc2hvdWxkDQpj YXJyeSBTRlJBTUVzLiBJZiB5b3Ugc3RhcnRzIHB1dHRpbmcgaW4gb3RoZXIgYmluYXJ5IG9iamVj dHMgaW50byBpdCwgdGhlbiB5b3UNCmNyZWF0ZSBhIG5ldyBkZW11bHRpcGxleGluZyBwb2ludCBm b3IgZm9ybWF0IGJldHdlZW4gdGhlIFJUUCBwYXlsb2FkIGZvcm1hdCBhbmQNCnRoZSBTRlJBTUUg cHJvY2Vzc2luZy4gVGhhdCBhcHBlYXJzIHVubW90aXZhdGVkLiANCg0KPiANCj4gDQo+ID4gWy4u Ll0NCj4gPiBNYXliZSBvbmUgd2F5IGZvcndhcmQgaXMgdG8gYnJlYWsgdGhlIHBhcmFncmFwaCB0 YWxraW5nIGFib3V0IHNpZ25hbGxpbmcgYW5kDQo+ID4gUlRQDQo+ID4gcGF5bG9hZCBmb3JtYXQg aW50byB0d28gZGlmZmVyZW50IHBhcmFncmFwaC4gV2hlcmUgdGhlIFJUUCBwYXlsb2FkIGZvcm1h dA0KPiA+IG5lZWQNCj4gPiBmb3Igc2lnbmFsbGluZyBpcyBub3QgYXNzb2NpYXRlZCB3aXRoIHRo ZSBoaWdoZXIgbGV2ZWwgbmVlZCBmb3IgU0ZSQU1FDQo+ID4gc2lnbmFsbGluZyBvdmVyIGZvciBl eGFtcGxlIGEgU0lQIHN5c3RlbS4gV2hpY2ggSSBhbSBmaW5lIHdpdGggZXhjbHVkaW5nDQo+ID4g ZXhwbGljaXRseS4NCj4gPiANCj4gPiBTbyBqdXN0IHRhbGtpbmcgYWJvdXQgdGhlIFJUUCBQYXls b2FkIGZvcm1hdC4gSSB0aGluayB0aGlzIGRvIG5lZWQgYSBtb2RlbA0KPiA+IGZvcg0KPiA+IGhv dyBhbiBSVFAgU0ZVIGlzIGdvaW5nIHRvIGJlIGFibGUgdG8gZG8gc3dpdGNoaW5nIG9uIGl0LiBT aG91bGRuJ3QgdGhhdCBiZQ0KPiA+IGluDQo+ID4gc2NvcGU/DQo+IA0KPiBOb3RlIHRoYXQgdGhl IFJUUCBwYXlsb2FkIGZvcm1hdCBtYXkgbm90IGJlIHRoZSBvbmUgcHJvdmlkaW5nIHRoZSANCj4g c3dpdGNoaW5nIGluZm9ybWF0aW9uIGZvciBhbiBTRlUuIEl0IGlzIG11Y2ggY2xlYW5lciB0byBj YXJyeSB0aGF0IA0KPiBpbmZvcm1hdGlvbiBpbiBhIG5ldyAoaG9wLWJ5LWhvcCBlbmNyeXB0ZWQp IGhlYWRlciBleHRlbnNpb24gc28gdGhlIA0KPiBwYXlsb2FkIGRvZXMgbm90IG5lZWQgdG8gYmUg cGFyc2VyIGJ5IHRoZSBTRlUgYXQgYWxsLCBzbyB0aGUgDQo+IHBhY2tldGl6YXRpb24gY2FuIGJl ICJwYXlsb2FkLWFnbm9zdGljIi4NCg0KDQpZZXMsIEkgYWdyZWUgdGhhdCBwdXR0aW5nIHRoZSBs YXllciBkZXBlbmRlbmN5IGluZm9ybWF0aW9uIGludG8gYW4gcGF5bG9hZA0KZXh0ZXJuYWwgaGVh ZGVyIGV4dGVuc2lvbiBldGMgaXMgdmVyeSByZWFzb25hYmxlLiBIb3dldmVyLCB0aGUgUlRQIHBh eWxvYWQNCmZvcm1hdCB3aWxsIG5lZWQgdG8gZGlzY3VzcyB0aGlzIG5lZWQgYW5kIHBvdGVudGlh bGx5IHJlY29tbWVuZCBhIHBhcnRpY3VsYXINCm1ldGhvZCBmb3IgY2FycnlpbmcgdGhlIGRlcGVu ZGVuY3kgaW5mb3JtYXRpb24gd2l0aGluIFJUUC4NCg0KU28gdG8gY29ubHVkZSBJIHRoaW5rIHRo ZXJlIGlzIG9uZSBjaGFydGVyIHJlbGF0ZWQgcXVlc3Rpb24gaGVyZS4NCg0KU2hvdWxkIHRoZSBS VFAgcGF5bG9hZCBmb3JtYXQgYXNwZWN0IG9mIHRoZSBjaGFydGVyIGJlIG1vcmUgZXhwbGljaXQg aW4gdGhhdCBpdA0KbmVlZHMgdG8gZGlzdWNzcyB0aGUgZ2VuZXJhbCBtb2RlbCBvZiBob3cgdG8g dXNlIFNGUkFNRSBhbmQgaG93IGFuIGFwcGxpY2F0aW9uDQpjYW4gdXNlIHRoZSBmYWNpbGl0aWVz IG9mIFJUUCB0byBnZXQgZ29vZCBwZXJmb3JtYW5jZSBmcm9tIFJUUCBtZWNoYW5pc20gbGlrZQ0K RkVDIGFuZCByZXRyYW5zbWlzc2lvbj8gDQoNCiANCkNoZWVycw0KDQpNYWdudXMgV2VzdGVybHVu ZCANCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpOZXR3b3JrcywgRXJpY3Nzb24gUmVzZWFyY2gNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCkVyaWNzc29uIEFCICAgICAgICAgICAgICAgICB8IFBob25lICArNDYgMTAgNzE0 ODI4Nw0KVG9yc2hhbW5zZ2F0YW4gMjMgICAgICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5 DQpTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW4gfCBtYWlsdG86IG1hZ251cy53ZXN0ZXJsdW5k QGVyaWNzc29uLmNvbQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg== From nobody Fri Sep 11 02:10:34 2020 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 4CE773A0C1D; Fri, 11 Sep 2020 02:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, 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 WFCF8vHi7slH; Fri, 11 Sep 2020 02:09:39 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150084.outbound.protection.outlook.com [40.107.15.84]) (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 6F2273A0C16; Fri, 11 Sep 2020 02:09:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z+KUl8k3jP6BvX66U+kldJIQbcfK/dMhzEwqoKE0qkLrJKw/8NEAkfg5BWb3eq4ZTO1mBo7Z+XPL5t+AK0XmVItB1rqQUoVky8KD2LMz5evqQU/I32nR76YfkoOSUdG+y13iFAepyhf07Q0Y7mwn0lMPdS9GMsca6dTdRejpMxCoP1A6d+3zFoF0/BuzEmNLZrAKtm0c94+Eh26kRNGdI6Zn888EvOA/cHRlHRi0dd9NyoDAPjPH9Ah3SlUhS9OUoSfPD6lQwbOCNHy6GZvpRj6BHt4l+RNS7OugKa/gB//u09ZKFStSgUpapTLra0altiuz8wChlNs7g4heGwcxPw== 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=g8rXYZWgApzew/IpwNfdG/MduX9Xr9KYk0OCG7igin0=; b=Mu9+uqdI09PI5JQoOcAhSpjeHnhRWN8MUaBrZ3bjM2/hn1SP/E2geQRhjJAJm9Fva3eHkQUaIvA5zJiRN6VsK5FGucE4pXdHXhOfn/AeKnSnx3RGUWx4AQMeh8rnUNPELEyNlc7xvw4uRkcC5JBuyq1YrfLxx+JtVaT3oraLOePLa+46A6CWTeoOx4VKF08yWAuX4mxGXrNJm+S3eaFFNDUNCnm0x258dTpgyMYCVj4ehNRNM0HfFuVNWlnppTg7WzeaOVWeTwN5QEHP+acZcGZo0C8KrJroEd8q1iCZtagWHD/PyKsTajefYUX7UM+GH58ACfeWUFEMXCHhJ0lBoA== 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=g8rXYZWgApzew/IpwNfdG/MduX9Xr9KYk0OCG7igin0=; b=deXBxfaOX2899ki1Q+gPOWhWmKs1JDRBEqcy2S3Iwzt7VHlvQsu50Cj7U0EjKsoJM7Z1bkx2iSY7w7EUvd8XHICck6fwhlT3Cbx5PP4u1aZTIl/CXAJTtOyjlJ0YdilZbnYhzyeh5X2AfRYf8J6qaJjU55p3fSG87YU417NZsrg= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR07MB4169.eurprd07.prod.outlook.com (2603:10a6:7:9d::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3370.7; Fri, 11 Sep 2020 09:09:03 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::b56f:9a8e:3399:aaa3]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::b56f:9a8e:3399:aaa3%7]) with mapi id 15.20.3370.016; Fri, 11 Sep 2020 09:09:03 +0000 From: Magnus Westerlund To: "magnus.westerlund=40ericsson.com@dmarc.ietf.org" , "sergio.garcia.murillo@cosmosoftware.io" , "rlb@ipv.sx" CC: "dispatch@ietf.org" , "iesg@ietf.org" , "sframe-chairs@ietf.org" , "sframe@ietf.org" Thread-Topic: [Sframe] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) Thread-Index: AQHWhTXfuLaYkFC4LEWqC8j5AGiLAKlh8DkAgAASwICAALgzgIAAV8mAgAAZAQA= Date: Fri, 11 Sep 2020 09:09:03 +0000 Message-ID: References: <159949693494.2875.16993532753477402380@ietfa.amsl.com> <5c6c96621b29ebf4b1f84e53ae3a414c9d0ec3a5.camel@ericsson.com> In-Reply-To: <5c6c96621b29ebf4b1f84e53ae3a414c9d0ec3a5.camel@ericsson.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.81] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e25b109e-cc22-4389-8aa2-08d85632543c x-ms-traffictypediagnostic: HE1PR07MB4169: 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: 3HAwJr6/+9oNn9nnURQ6tt+/AUbzuD0x6hDNsA1ciJ00OcgzVtSYnx5eiQVv5WGg8Huj8RIvo+IxMbTQdxi105ZkiFhfuIzztmgF3Ww8Yeee5UViTuNjTrsRuylN6j4U4gd3LmsdlkePPR0Sx8FGBnAVI72FOHlEzlDW2ULTR5RKuonahXsY86ek4/N8MlAQPVxV7f/3r21BZ1g/AtDpRQ59KF61c+wrSbgHOGeWu9Hchlqwv/O8aYNRWAOIpt7UI9txNqn+5qoz84wgkTAPhcHm1qqcziDE3oVxp8SegktBjHW76E3Vns4UvKbguDNi+hVdaPKcb++DP6TL5L5R1xe05mhkk3VlkZUxJk/WQjDCFzW18Qng+/eU72mQcODd8gSTeEDaqYy5+LTXSIiy4oMEZ+jkgLil6zZWsSJBGI4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(346002)(376002)(39860400002)(366004)(6486002)(54906003)(316002)(186003)(478600001)(110136005)(6506007)(53546011)(36756003)(86362001)(26005)(4326008)(8676002)(8936002)(6512007)(2906002)(5660300002)(44832011)(76116006)(64756008)(91956017)(66446008)(66946007)(66556008)(71200400001)(2616005)(66476007)(99106002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: F78AMUy1ODeCRBytxEhddh37fMNSNKCgn5QvE/vhzBmWB7mj46ZJe7XUd2VbUzOak65PZ505bRNHhLOWe2kvrIJujXFSVc2KMhl0ay5HOQokTLuK5by5rO7z/osTD2sURuz0u00Dv8sdttAGGf+anO+Z5Rcfh67o64bciraGGjqAGS43E5SX7CvWnvC2vmn0+pO4kKe7fCiCSOc6GJOZOyImQoq/Mj3kABzll588yga7+Tm5Hi5mbObvCC+BzWdgyF43JC6dLUg38pm9JC2p4Mg5iyM/c1+VFK+h3DbmAwv2ZCvWIBna9DIxAr0TAlq7EYufvOjmcoq8Ri+/JcpNq1pIHs9s6O1aQjDw8gvqpJr4rdTpxOv5OKk+Xph0VXtyF3nSExEmvds/bv4vdUC6k+mOcA+DPuX+A2BT2SX3CLRBf4tBMMNrPQQKncSbJPFI228cG0+8uVsMJKE/8lcvhWQololAYb2fDbmYM59/QJH1oCfJYfnsEb+5DQdyQtswE6AmAil0AX7byTOqVv4ZJ/NYcUvOXGyxmY1DDSrJa1fcP3JbDR1lmwup8oH7TYZtdudJGYpb3/kJwqQINPEhGoHuBrJOqMYyQxcOGbSwiIjJzxU41f0p5p0RS1auwSvJbS5uTTH/NVz+ZAb1l8TMew== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <411E1D34E8027C46951C8C1BE35F2766@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e25b109e-cc22-4389-8aa2-08d85632543c X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2020 09:09:03.3103 (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: zTv8LMwaQDko4ZC/X90xSL76mFR6VHbhOWcKqUSQWUAi2t0s56sYN+6/slf5atgFrCJ9cHDr8L8nNOEIa2UREBpzYHqoKCUSn8xNYFFPRiA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4169 Archived-At: Subject: Re: [Sframe] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2020 09:09:42 -0000 SGksDQoNCkkgZGlkIGZvcmdvdCBvbmUgYXNwZWN0IHRoYXQgSSBzaG91bGQgaGF2ZSBwaWNrZWQg dXAgZWFybGllci4NCg0KVGhlIHJlbGF0aW9uc2hpcCB0byBBVlRDT1JFIGluIHRoaXMgd29yay4g Q2FuIHdlIGJlIGV4cGljaXQgaWYgdGhlIFNGUkFNRSBXRyBkbw0KdGhlIFJUUCBQYXlsb2FkIGZv cm1hdCBhbmQgdGhlbiBjb3JkaW5hdGUgd2l0aCBBVlRDT1JFIGFuZCBoYXZlIGpvaW50IFdHIExh c3QNCmNhbGwgb3IgaWYgdGhlIFJUUCBwYXlsb2FkIGZvcm1hdCBpcyBkb25lIGluIEFWVENPUkU/ IEkgYW0gZmluZSB3aXRoIHRoZSBmaXJzdC4NCg0KQ2hlZXJzDQoNCk1hZ251cw0KDQpPbiBGcmks IDIwMjAtMDktMTEgYXQgMDc6MzkgKzAwMDAsIE1hZ251cyBXZXN0ZXJsdW5kIHdyb3RlOg0KPiBI aSwNCj4gDQo+IEkgdGhpbmsgd2UgYXJlIG1ha2luZyBnb29kIHByb2dyZXNzIGhlcmUuIA0KPiAN Cj4gT24gRnJpLCAyMDIwLTA5LTExIGF0IDA0OjI1ICswMjAwLCBTZXJnaW8gR2FyY2lhIE11cmls bG8gd3JvdGU6DQo+ID4gT24gMTAvMDkvMjAyMCAxNzoyNiwgTWFnbnVzIFdlc3Rlcmx1bmQgd3Jv dGU6DQo+ID4gDQo+ID4gPiBbLi4uXSBIb3dldmVyLCB0aGUgaXNzdWUgSSByZWFsbHkgcmVhY3Rl ZCB0byBoZXJlIGlzIHRoZSBmYWN0IHRoYXQgdGhlDQo+ID4gPiBjaGFydGVyIGlzDQo+ID4gPiBz dGF0aW5nIHRoYXQgaXQgc2hvdWxkIGRvIGFuIFJUUCBwYXlsb2FkIGZvcm1hdC4gV2hlbiBkb2lu ZyBhbiBSVFAgcGF5bG9hZA0KPiA+ID4gZm9ybWF0IEkgdGhpbmsgaXQgaXMgcHJlLW1hdHVyZSBv ZiB0aGUgY2hhcnRlciB0byBzYXkgdGhhdCB0aGUgc2lnbmFsbGluZw0KPiA+ID4gcmVxdWlyZWQg Zm9yIHRoZSBSVFAgcGF5bG9hZCBmb3JhbXQgaXMgb3V0IG9mIHNjb3BlLiBJIHRoaW5rIHRoYXQg bmVlZHMgdG8NCj4gPiA+IGJlDQo+ID4gPiBwYXJ0IG9mIHRoZSBwcm9jZXNzIHRvIGRpc2N1c3Mg aW4gdGhlIFJUUCBwYXlsb2FkIGZvcm1hdCBob3cgYW4gUlRQDQo+ID4gPiBtaWRkbGVib3gNCj4g PiA+IGNhbiB1c2UgdGhlIHBheWxvYWQgZm9ybWF0LCBhbmQgYW55IFJUUCBleHRlbnNpb24gbGlr ZSBmcmFtZSBtYXJraW5nIHRvDQo+ID4gPiBmaWd1cmUNCj4gPiA+IG91dCB3aGF0IHRvIGRvIHdo ZW4gc3dpdGNoaW5nLiBUaGF0IFJUUCBwYXlsb2FkIGZvcm1hdCB3aWxsIHJlcXVpcmUgc29tZQ0K PiA+ID4gY29uZmlndXJhdGlvbiBjYXBhYmlsaXR5IHRvIGJlIGFibGUgdG8gd29yay4NCj4gPiA+ IA0KPiA+ID4gU28gd2hhdCBJIGFtIHJlYWxseSBhc2tpbmcgZm9yIGlzIHRoZSByZW1vdmFibGUg b2YgdGhlIHJlc3RyaWN0aW9uIHRoYXQNCj4gPiA+IHByZXZlbnRzDQo+ID4gPiBhIHJlZ3VsYXIg UlRQIHBheWxvYWQgZm9ybWF0IGRlc2lnbiB3b3JrLiBBbmQgc3RhdGluZyB0aGF0IFNEUCBpcyBv dXQgb2YNCj4gPiA+IHNjb3BlDQo+ID4gPiBpbXBsaWVzIHRoYXQgdG8gbWUgaW4gdGhlIGRpcmVj dCBjb250ZXh0IG9mIHRoZSBwYXlsb2FkIGZvcm1hdC4NCj4gPiANCj4gPiANCj4gPiBJIGFncmVl LiBBcyBJIHJlYWQgdGhlIGNoYXJ0ZXIsIFNEUCBpcyBvdXQgb2YgdGhlIHNjb3BlIGZvciANCj4g PiBuZWdvdGlhdGluZy9zaWduYWxpbmcgdGhlIHVzYWdlIG9mIFNGcmFtZSBhbmQgdGhlIHBhcmFt ZXRlcnMgdGhhdCBtYXkgYmUgDQo+ID4gdXNlZCBmb3IgZW5jcnlwdGlvbi9kZWNyeXB0aW9uLg0K PiANCj4gVGhlIHNpZ25hbGxpbmcgZm9yIHdoYXQgaXMgaW4gdGhlIFNGUkFNRSBpcyBvdXQgb2Yg c2NvcGUgYWxzby4gDQo+IA0KPiBTbyBkbyBJIGFzc3VtZSBjb3JyZWN0bHkgdGhhdCB0aGUgaWRl YSBpcyB0aGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllciB1c2luZw0KPiBTRlJBTUUgaWYgaXQgaGF2 ZXMgbXVsdGlwbGUgaW5kZXBlbmRlbnQgb3Igc2V0cyBvZiBkZXBlbmRlbnQgc3RyZWFtcyB0aGVy ZQ0KPiB3aWxsDQo+IGJlIG5vIHN1cHBvcnQgZm9yIHRoYXQgYXNwZWN0IGluIFNGUkFNRSBsYXll cj8gSW5zdGVhZCBpdCBpcyB1cCB0byB0aGUNCj4gYXBwbGljYXRpb24gdG8gcHV0IHN1Y2ggaW5m b3JtYXRpb24gdG8gZWl0aGVyIHB1dCBpdCBpbnNpZGUgdGhlIGVuY2Fwc3VhbHRlZA0KPiBwYXJ0 IG9mIHRoZSBTRlJBTUUgb3IgbWFwIGl0IHRvIHRoZSBsb3dlciB0cmFuc3BvcnQgbGF5ZXIsIGxp a2UgdG8gUlRQIFNTUkNzDQo+IGFuZA0KPiBleHRlbnNpb24gaW5mb3JtYXRpb24uIA0KPiANCj4g PiANCj4gPiBIb3dldmVyLCBpZiB0aGUgZW5jcnlwdGVkIG91dHB1dCBpcyBnb2luZyB0byBiZSB0 cmFuc21pdHRlZCBvdmVyIFJUUCANCj4gPiB1c2luZyBhIG5ldyBwYWNrZXRpemF0aW9uIGZvcm1h dCwgd2UgbmVlZCB0byBhZGRyZXNzIGhvdyB0byBuZWdvdGlhdGUgDQo+ID4gdGhhdCBpbiB0aGUg U0RQLg0KPiANCj4gR29vZA0KPiANCj4gPiBOb3RlIHRoYXQgdGhpcyBuZXcgcGFja2V0aXphdGlv biBmb3JtYXQgd2lsbCBub3Qgb25seSBiZSBhbGlkIGZvciANCj4gPiB0cmFuc3BvcnRpbmcgZW5j cnlwdGVkIGZyYW1lcyAoU0ZyYW1lIG9yIG5vdCkgYnV0IGV2ZW4gYW55IG90aGVyIA0KPiA+IGF1 ZGlvL3ZpZGVvIGZyYW1lcy4NCj4gDQo+IEkgdW5kZXJzdGFuZCB0aGUgcG90ZW50aWFsIGV4aXN0 cy4gSG93ZXZlciwgdGhlIHJlY29tbWVuZGF0aW9uIGZvciBSVFAgaGFzDQo+IGJlZW4NCj4gdG8g dHJ5IHRvIGNvbnNpZGVyIEFwcGxpY2F0aW9uIExldmVsIEZyYW1pbmcuIEluIHRoZSBjYXNlIG9m IFNGUkFNRSB0aGF0DQo+IGNvbnNpZGVyYXRpb24gbW92ZXMgdXAgYWJvdmUgU0ZSQU1FIGluIHRo ZSBjaG9pY2Ugb2YgaG93IGRhdGEgaXMgc3BsaXQgaW50bw0KPiBTRlJBTUVzLiBIb3dldmVyLCBo YXZpbmcgYW4gUlRQIHBheWxhb2QgZm9ybWF0IGZvciBTRlJBTUUsIHRoZW4gdGhhdCBzaG91bGQN Cj4gY2FycnkgU0ZSQU1Fcy4gSWYgeW91IHN0YXJ0cyBwdXR0aW5nIGluIG90aGVyIGJpbmFyeSBv YmplY3RzIGludG8gaXQsIHRoZW4geW91DQo+IGNyZWF0ZSBhIG5ldyBkZW11bHRpcGxleGluZyBw b2ludCBmb3IgZm9ybWF0IGJldHdlZW4gdGhlIFJUUCBwYXlsb2FkIGZvcm1hdA0KPiBhbmQNCj4g dGhlIFNGUkFNRSBwcm9jZXNzaW5nLiBUaGF0IGFwcGVhcnMgdW5tb3RpdmF0ZWQuIA0KPiANCj4g PiANCj4gPiANCj4gPiA+IFsuLi5dDQo+ID4gPiBNYXliZSBvbmUgd2F5IGZvcndhcmQgaXMgdG8g YnJlYWsgdGhlIHBhcmFncmFwaCB0YWxraW5nIGFib3V0IHNpZ25hbGxpbmcNCj4gPiA+IGFuZA0K PiA+ID4gUlRQDQo+ID4gPiBwYXlsb2FkIGZvcm1hdCBpbnRvIHR3byBkaWZmZXJlbnQgcGFyYWdy YXBoLiBXaGVyZSB0aGUgUlRQIHBheWxvYWQgZm9ybWF0DQo+ID4gPiBuZWVkDQo+ID4gPiBmb3Ig c2lnbmFsbGluZyBpcyBub3QgYXNzb2NpYXRlZCB3aXRoIHRoZSBoaWdoZXIgbGV2ZWwgbmVlZCBm b3IgU0ZSQU1FDQo+ID4gPiBzaWduYWxsaW5nIG92ZXIgZm9yIGV4YW1wbGUgYSBTSVAgc3lzdGVt LiBXaGljaCBJIGFtIGZpbmUgd2l0aCBleGNsdWRpbmcNCj4gPiA+IGV4cGxpY2l0bHkuDQo+ID4g PiANCj4gPiA+IFNvIGp1c3QgdGFsa2luZyBhYm91dCB0aGUgUlRQIFBheWxvYWQgZm9ybWF0LiBJ IHRoaW5rIHRoaXMgZG8gbmVlZCBhIG1vZGVsDQo+ID4gPiBmb3INCj4gPiA+IGhvdyBhbiBSVFAg U0ZVIGlzIGdvaW5nIHRvIGJlIGFibGUgdG8gZG8gc3dpdGNoaW5nIG9uIGl0LiBTaG91bGRuJ3Qg dGhhdA0KPiA+ID4gYmUNCj4gPiA+IGluDQo+ID4gPiBzY29wZT8NCj4gPiANCj4gPiBOb3RlIHRo YXQgdGhlIFJUUCBwYXlsb2FkIGZvcm1hdCBtYXkgbm90IGJlIHRoZSBvbmUgcHJvdmlkaW5nIHRo ZSANCj4gPiBzd2l0Y2hpbmcgaW5mb3JtYXRpb24gZm9yIGFuIFNGVS4gSXQgaXMgbXVjaCBjbGVh bmVyIHRvIGNhcnJ5IHRoYXQgDQo+ID4gaW5mb3JtYXRpb24gaW4gYSBuZXcgKGhvcC1ieS1ob3Ag ZW5jcnlwdGVkKSBoZWFkZXIgZXh0ZW5zaW9uIHNvIHRoZSANCj4gPiBwYXlsb2FkIGRvZXMgbm90 IG5lZWQgdG8gYmUgcGFyc2VyIGJ5IHRoZSBTRlUgYXQgYWxsLCBzbyB0aGUgDQo+ID4gcGFja2V0 aXphdGlvbiBjYW4gYmUgInBheWxvYWQtYWdub3N0aWMiLg0KPiANCj4gDQo+IFllcywgSSBhZ3Jl ZSB0aGF0IHB1dHRpbmcgdGhlIGxheWVyIGRlcGVuZGVuY3kgaW5mb3JtYXRpb24gaW50byBhbiBw YXlsb2FkDQo+IGV4dGVybmFsIGhlYWRlciBleHRlbnNpb24gZXRjIGlzIHZlcnkgcmVhc29uYWJs ZS4gSG93ZXZlciwgdGhlIFJUUCBwYXlsb2FkDQo+IGZvcm1hdCB3aWxsIG5lZWQgdG8gZGlzY3Vz cyB0aGlzIG5lZWQgYW5kIHBvdGVudGlhbGx5IHJlY29tbWVuZCBhIHBhcnRpY3VsYXINCj4gbWV0 aG9kIGZvciBjYXJyeWluZyB0aGUgZGVwZW5kZW5jeSBpbmZvcm1hdGlvbiB3aXRoaW4gUlRQLg0K PiANCj4gU28gdG8gY29ubHVkZSBJIHRoaW5rIHRoZXJlIGlzIG9uZSBjaGFydGVyIHJlbGF0ZWQg cXVlc3Rpb24gaGVyZS4NCj4gDQo+IFNob3VsZCB0aGUgUlRQIHBheWxvYWQgZm9ybWF0IGFzcGVj dCBvZiB0aGUgY2hhcnRlciBiZSBtb3JlIGV4cGxpY2l0IGluIHRoYXQNCj4gaXQNCj4gbmVlZHMg dG8gZGlzdWNzcyB0aGUgZ2VuZXJhbCBtb2RlbCBvZiBob3cgdG8gdXNlIFNGUkFNRSBhbmQgaG93 IGFuIGFwcGxpY2F0aW9uDQo+IGNhbiB1c2UgdGhlIGZhY2lsaXRpZXMgb2YgUlRQIHRvIGdldCBn b29kIHBlcmZvcm1hbmNlIGZyb20gUlRQIG1lY2hhbmlzbSBsaWtlDQo+IEZFQyBhbmQgcmV0cmFu c21pc3Npb24/IA0KPiANCj4gIA0KPiBDaGVlcnMNCj4gDQo+IE1hZ251cyBXZXN0ZXJsdW5kIA0K PiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gTmV0d29ya3MsIEVyaWNzc29uIFJlc2VhcmNoDQo+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gRXJpY3Nzb24gQUIgICAgICAgICAgICAgICAgIHwgUGhvbmUgICs0 NiAxMCA3MTQ4Mjg3DQo+IFRvcnNoYW1uc2dhdGFuIDIzICAgICAgICAgICB8IE1vYmlsZSArNDYg NzMgMDk0OTA3OQ0KPiBTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW4gfCBtYWlsdG86IG1hZ251 cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiANCi0tIA0K Q2hlZXJzDQoNCk1hZ251cyBXZXN0ZXJsdW5kIA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCk5ldHdvcmtz LCBFcmljc3NvbiBSZXNlYXJjaA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRXJpY3Nzb24gQUIgICAgICAgICAg ICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQpUb3JzaGFtbnNnYXRhbiAyMyAgICAgICAg ICAgfCBNb2JpbGUgKzQ2IDczIDA5NDkwNzkNClNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbiB8 IG1haWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN Cg0K From nobody Fri Sep 11 03:04:19 2020 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 98C403A0D72; Fri, 11 Sep 2020 03:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 yZE6345KQL00; Fri, 11 Sep 2020 03:04:07 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 3579B3A0D78; Fri, 11 Sep 2020 03:04:07 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id z1so10888485wrt.3; Fri, 11 Sep 2020 03:04:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=Z93yAL/eJzU4jl5Ta0Xsk1TPP7NIP7Hu12BbivJcyCk=; b=ntuVq6v1wc9Hc+hNrEs727jQEHgyRYSpRg4GOSk3gyMEWpi3ApHErg3nyX65C2WJT0 WCYU5hP/nJIHElcTJUTNg1jxkHsXW8+dvBhgSTWnhVQHyrkQ9hS0lNqfwyHIhslaKLXC a/4f/I7Y41oZNdD7jOjEUWt008wHDmqE3NMZov5ZDg2bCHubFeDC3wYQIWaAwSg9q0Qy CBPCNkRkQQegzbuBJTdzOKMjPSMWjcfuJ01pru2iqx1GchN5j01y6xlcTm9GSoefpoWL w1IGVvudaF3k1kwmZSmrX3XpiDHGTWLYJ41R/4jX4Y/aIScwe/HQK1JL0P7MyX2rbTLd y86w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Z93yAL/eJzU4jl5Ta0Xsk1TPP7NIP7Hu12BbivJcyCk=; b=jn0+gCmdGSecW54mdDhY/OWAxcadnSQb1JZtZom9Eh/kxeDDpChj7W6fVMhEXWUzpa Zia2db5KjoxddBK7aNGeQF/fBnqxbES0J+7VG8bZF6w0/JdSd+qzbDv760U1DgX2Fsg0 7fwyMA0ioWWtY4wE6OSfQtNODDmQBscvbRUYxj2ReAQSpwVZMQmAqyn4qUsPQGz4ttAT BBk6hylMDfg3Hb+PqEFySDmJ8B6ZL81uzFnMp6G3fQw37cnNzL+uuBeMuXO+9FZZ2wVb LvK5MG6WnoySZbQAoRnYTzSvtj6oJ4ZUwK4/f4AvQEgROyuErqFiM/XfIn2KaWG1so1T sgnw== X-Gm-Message-State: AOAM530R8dOTx0Cw2vyZNwvIjAo0gECOHH+ld+JOkPEuhH2X1Bp3FSXG ktXKNnuQI55TJhq+jgkqDInBTBm6/y6YfaVa X-Google-Smtp-Source: ABdhPJz14pYiZ/y8OfiHHlRIhuA6SJCtVWVLgcjpZQrA5Fp89CHKG3SkimNkj74zKGgA0iJNq7wFFA== X-Received: by 2002:adf:dc47:: with SMTP id m7mr1278310wrj.100.1599818645239; Fri, 11 Sep 2020 03:04:05 -0700 (PDT) Received: from [192.168.0.11] (79.108.125.160.dyn.user.ono.com. [79.108.125.160]) by smtp.googlemail.com with ESMTPSA id p11sm3322304wma.11.2020.09.11.03.04.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Sep 2020 03:04:04 -0700 (PDT) To: Magnus Westerlund , "sergio.garcia.murillo@cosmosoftware.io" , "rlb@ipv.sx" Cc: "sframe-chairs@ietf.org" , "dispatch@ietf.org" , "iesg@ietf.org" , "sframe@ietf.org" References: <159949693494.2875.16993532753477402380@ietfa.amsl.com> <5c6c96621b29ebf4b1f84e53ae3a414c9d0ec3a5.camel@ericsson.com> From: Sergio Garcia Murillo Message-ID: <05085c6c-0c30-a407-8f41-b6c9be8100bc@gmail.com> Date: Fri, 11 Sep 2020 12:04:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <5c6c96621b29ebf4b1f84e53ae3a414c9d0ec3a5.camel@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Sframe] [dispatch] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2020 10:04:10 -0000 On 11/09/2020 9:39, Magnus Westerlund wrote: > Hi, > > I think we are making good progress here. > > On Fri, 2020-09-11 at 04:25 +0200, Sergio Garcia Murillo wrote: >> On 10/09/2020 17:26, Magnus Westerlund wrote: >> >>> [...] However, the issue I really reacted to here is the fact that the >>> charter is >>> stating that it should do an RTP payload format. When doing an RTP payload >>> format I think it is pre-mature of the charter to say that the signalling >>> required for the RTP payload foramt is out of scope. I think that needs to >>> be >>> part of the process to discuss in the RTP payload format how an RTP >>> middlebox >>> can use the payload format, and any RTP extension like frame marking to >>> figure >>> out what to do when switching. That RTP payload format will require some >>> configuration capability to be able to work. >>> >>> So what I am really asking for is the removable of the restriction that >>> prevents >>> a regular RTP payload format design work. And stating that SDP is out of >>> scope >>> implies that to me in the direct context of the payload format. >> >> I agree. As I read the charter, SDP is out of the scope for >> negotiating/signaling the usage of SFrame and the parameters that may be >> used for encryption/decryption. > The signalling for what is in the SFRAME is out of scope also. > > So do I assume correctly that the idea is that the application layer using > SFRAME if it haves multiple independent or sets of dependent streams there will > be no support for that aspect in SFRAME layer? Instead it is up to the > application to put such information to either put it inside the encapsualted > part of the SFRAME or map it to the lower transport layer, like to RTP SSRCs and > extension information. If i understood you correctly, SFrame is kind of agnostic to the media streams. Currently it has a single global frame counter for all the transport, so the number of streams/dependency between them is not known/needed by SFrame. > >> However, if the encrypted output is going to be transmitted over RTP >> using a new packetization format, we need to address how to negotiate >> that in the SDP. > Good > >> Note that this new packetization format will not only be alid for >> transporting encrypted frames (SFrame or not) but even any other >> audio/video frames. > I understand the potential exists. However, the recommendation for RTP has been > to try to consider Application Level Framing. In the case of SFRAME that > consideration moves up above SFRAME in the choice of how data is split into > SFRAMEs. However, having an RTP paylaod format for SFRAME, then that should > carry SFRAMEs. If you starts putting in other binary objects into it, then you > create a new demultiplexing point for format between the RTP payload format and > the SFRAME processing. That appears unmotivated. Note that SFRAME is not the only encryption possible with w3c insertable streams, it is up to the application to define its own crypto if they want. So the payload must be able to transport non-SFRAME opaque blobs. > >> >>> [...] >>> Maybe one way forward is to break the paragraph talking about signalling and >>> RTP >>> payload format into two different paragraph. Where the RTP payload format >>> need >>> for signalling is not associated with the higher level need for SFRAME >>> signalling over for example a SIP system. Which I am fine with excluding >>> explicitly. >>> >>> So just talking about the RTP Payload format. I think this do need a model >>> for >>> how an RTP SFU is going to be able to do switching on it. Shouldn't that be >>> in >>> scope? >> Note that the RTP payload format may not be the one providing the >> switching information for an SFU. It is much cleaner to carry that >> information in a new (hop-by-hop encrypted) header extension so the >> payload does not need to be parser by the SFU at all, so the >> packetization can be "payload-agnostic". > > Yes, I agree that putting the layer dependency information into an payload > external header extension etc is very reasonable. However, the RTP payload > format will need to discuss this need and potentially recommend a particular > method for carrying the dependency information within RTP. > > So to conlude I think there is one charter related question here. > > Should the RTP payload format aspect of the charter be more explicit in that it > needs to disucss the general model of how to use SFRAME and how an application > can use the facilities of RTP to get good performance from RTP mechanism like > FEC and retransmission? I don't think so, RTX and FEC frames MUST not be modified/affected by SFRAME/the new packetization format, so they work out of the box. We can be explicit about that in the chapter as a requirement. Best regards Sergio From nobody Fri Sep 11 04:19:39 2020 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 CC7233A0EC5; Fri, 11 Sep 2020 04:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 gTv7stk93cPb; Fri, 11 Sep 2020 04:19:30 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20049.outbound.protection.outlook.com [40.107.2.49]) (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 DF9C03A0486; Fri, 11 Sep 2020 04:19:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hVhVK4q+6B7BWrjIYjwKUuIaSUoKeaFBE8gjeElfZSw4sYtpXElwRMRZAQ6488a6W2mJuGrhsv17+JipTzKVW69FB0cO3lfX6GGgTOWFmm7XaXbhaXzDcuz34C/ZKAeRI++VwvE7zjk5Ec3PD7ea2jsLXoFYGk6dP+0FPebmEDWFOaYz/YPJy5kC8aZTPW2gjeXNly3mj6fSCf7MfmK3nZMplL0ziYCFdeeOrAi9lcOiPzmjImU1Mgo4J/A0gUXHj/fJbf/AUBKvqBPcl/1S42Txof7SrlBTPCl+rfbJp5cdNLZWuFtlYUwruWAng8OzA7BPXTUQ8+Doz2s1jnB9rA== 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=FjvIqEE96b/y3r5JqzArmWpeoC2Dlt5Up5GRufZoBI8=; b=OuRwNREnCze992SX+iGmSTxPTFEo2grUI94nqR6urSpt7IOykmM+ag50CpYZf+AM3qSzqmGqhw8TDyI5bXvXhOZx330/FhxuC8BbPLIWBuUkPFSod3yoOaBt33RI4M/3tQ5wUe/Br/wJuTlny3LPe4dx97PE2ig8iHGg1MQej3Ybw5QwWiZ5hEon2pZNvfVIX359HCv2tfnM753SmrMEF9q9OWojC66agcvlb/OPPh1T0IK1Y+ARBNAc1U3yz5IZ11erDzwPHukK58s2RlxKLYcMf4cBq3ap1pR/LPA8BGz0pW6kUgiL7dF3qZgJ88PILCnhFoefih3TJvBTqi+Qyg== 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=FjvIqEE96b/y3r5JqzArmWpeoC2Dlt5Up5GRufZoBI8=; b=XTPR8nhWtwrbQ2VhqllW69+CxsyGEX5+5noHb4/eLUa6pDUbe+SIujS/t6/7Vr9jdwu1WyUJWuQqPn6C59KjbzNvf7VTzlge79YxR/MrACG7DYi2nNN0WLEydvEjrBNilt2AujlblmvkjfWMfb6ZRHwN5rRs2qQOBAvCoT9YffI= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR0702MB3770.eurprd07.prod.outlook.com (2603:10a6:7:84::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.6; Fri, 11 Sep 2020 11:19:26 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::b56f:9a8e:3399:aaa3]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::b56f:9a8e:3399:aaa3%7]) with mapi id 15.20.3370.016; Fri, 11 Sep 2020 11:19:26 +0000 From: Magnus Westerlund To: "sergio.garcia.murillo@gmail.com" , "magnus.westerlund=40ericsson.com@dmarc.ietf.org" , "sergio.garcia.murillo@cosmosoftware.io" , "rlb@ipv.sx" CC: "sframe-chairs@ietf.org" , "dispatch@ietf.org" , "iesg@ietf.org" , "sframe@ietf.org" Thread-Topic: [dispatch] [Sframe] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) Thread-Index: AQHWhTXfuLaYkFC4LEWqC8j5AGiLAKlh8DkAgAASwICAALgzgIAAV8mAgAAoYICAAA/A0A== Date: Fri, 11 Sep 2020 11:19:26 +0000 Message-ID: References: <159949693494.2875.16993532753477402380@ietfa.amsl.com> <5c6c96621b29ebf4b1f84e53ae3a414c9d0ec3a5.camel@ericsson.com> <05085c6c-0c30-a407-8f41-b6c9be8100bc@gmail.com> In-Reply-To: <05085c6c-0c30-a407-8f41-b6c9be8100bc@gmail.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: 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: [158.174.116.90] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8b0da932-423f-467d-a7a6-08d856448b1e x-ms-traffictypediagnostic: HE1PR0702MB3770: 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: uHp1Sy7jKjuNuIZ7AGcCdJpm8tnhG0Ma+3k0Y7cHBSqGj69eBr5vcsqWhJbGALiXQetEp5pjWVkZEkDcR81BaHiYHRwNw92RkgzMSvrCN/Snm0NnJHUNBaD6q1wtzao62aTxsJObloHhBLqCE0hrNTZri2zpvGOzyOPWZTx8CBp4RpGmOuoVBXgJvT9NpDwledshg4OAp4Q9e81+vA8eA9ajDOsOwI0BSEi2cFPdQVh8clqREqsmNPY/2lTJ0VyZhYGvNkbp6yIv7ALun1SiOy6S2cOPbDk3j9XKpkALP56Fu91x7ylQpL/9AEz5SLgQsxduyhONDs5w6FAbUXesiA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(366004)(136003)(376002)(346002)(396003)(76116006)(66946007)(66616009)(66476007)(66556008)(64756008)(4326008)(66446008)(2906002)(8676002)(7696005)(9686003)(26005)(52536014)(5660300002)(71200400001)(55016002)(33656002)(6506007)(54906003)(110136005)(478600001)(44832011)(8936002)(316002)(99936003)(83380400001)(86362001)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: UCCbUrDO3JQ4xrwa4gUiGw5peOp5dg3i6Z5OlaUtxIuGsKFVjwCSGRXF+Al0/02ctPrU7YdQMA6bAWqtIvpJJW4nnL4/n0bZG9Mv9Xso99M5k4XGy6N3357pkZ/Byz5jwPeZ7XUWcAATxOGq17Tyn+WnyRvSEejKJU6LsdFHbt6KpJSD0UPGkWLrh6cgHMMDI9MDB0qt5RileionXaphKm4+89nyLquM4mKt2VJqbMtNVAsR59fgeHeh8e5xijJ5HvGJ7hbd4DTMNuYdSnIz3zgIxjcogrjs4h7Eaf/m5KgXS4qLzJ5ibI6lz4ApVQJk40DZCJ9HBDFE5ILgicyN82LVj/i7Q9z/oeiGU76AUyLSQwrtX0IEUR/gTKuMmTEsRbSSqim0V6PYl1LD74pCQrhqZqM653YIsBL3oURxxiY6uqgcyqaiR2AeXqPrmd1dG7j3Cb5FKM76qcxvePvkIk1U82BEri47Odb8MtzNS+ddqJj98kLq440NlSJhR7zhPmkLHEp/u6Wosy8jD5Q7ZDNW8o5EW+IHJ7tU+B/fCcfcUrpdp4cie2KmPDDJ8Yep3ZEJK2Nh00V+zUi49cDuQ8+F7Z/SfzSmFADyn0B4R0mFUU7419QjshpieyceHqdaSOtfOt1KMDpOH+RPkw8aiA== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_004B_01D6883E.2B29D500" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8b0da932-423f-467d-a7a6-08d856448b1e X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2020 11:19:26.3202 (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: 8KBPwgocBGTAQfWRhouC48VWoaHd3MnDpAFqqQiynGO6dcqhdgv7LCkOoOy+BD6tF02VLaftoRHcWh0wwOh7mMXZTqWWIuJlcemY7q4dFp4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3770 Archived-At: Subject: Re: [Sframe] [dispatch] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2020 11:19:32 -0000 ------=_NextPart_000_004B_01D6883E.2B29D500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, > > So do I assume correctly that the idea is that the application layer > > using SFRAME if it haves multiple independent or sets of dependent > > streams there will be no support for that aspect in SFRAME layer? > > Instead it is up to the application to put such information to either > > put it inside the encapsualted part of the SFRAME or map it to the > > lower transport layer, like to RTP SSRCs and extension information. > > > If i understood you correctly, SFrame is kind of agnostic to the media > streams. Currently it has a single global frame counter for all the transport, so > the number of streams/dependency between them is not known/needed > by SFrame. Yes, and when using a multi-stream application with layered encoding being protected by SFRAME and transported over RTP with repair functions the high layer application will need to have a model for how it maps individual SFRAMEs to RTP layer functions to enable them to do their work. You get a very limited functionality if in an SFU system tries to send all over a single RTP SSRC. So this becomes a discussion in the RTP Payload format context when carrying SFRAMEs. > > > > > >> However, if the encrypted output is going to be transmitted over RTP > >> using a new packetization format, we need to address how to negotiate > >> that in the SDP. > > Good > > > >> Note that this new packetization format will not only be alid for > >> transporting encrypted frames (SFrame or not) but even any other > >> audio/video frames. > > I understand the potential exists. However, the recommendation for RTP > > has been to try to consider Application Level Framing. In the case of > > SFRAME that consideration moves up above SFRAME in the choice of how > > data is split into SFRAMEs. However, having an RTP paylaod format for > > SFRAME, then that should carry SFRAMEs. If you starts putting in other > > binary objects into it, then you create a new demultiplexing point for > > format between the RTP payload format and the SFRAME processing. That > appears unmotivated. > > > Note that SFRAME is not the only encryption possible with w3c insertable > streams, it is up to the application to define its own crypto if they want. So > the payload must be able to transport non-SFRAME opaque blobs. So I would consider this a misuse of the RTP payload format. The media type will be for SFRAMEs. I understand that you might not be able to prevent this in WebRTC. However, from an interoperability point of view you will be stating that this is SFRAMEs. RTP will not be able to tell a difference. But I don't see that this is will explicitly support carrying other things than SFRAME. Because that means bringing in other consideration including the security model for the E2E usage. > > > > Should the RTP payload format aspect of the charter be more explicit > > in that it needs to disucss the general model of how to use SFRAME and > > how an application can use the facilities of RTP to get good > > performance from RTP mechanism like FEC and retransmission? > > > I don't think so, RTX and FEC frames MUST not be modified/affected by > SFRAME/the new packetization format, so they work out of the box. We can > be explicit about that in the chapter as a requirement. > So I am not saying that RTX or FEC shall be modified. What I am saying is that the SFRAME payload format should discuss the impact on the performance of these functions depending on how you structure the SFRAMES across SSRCs. The most simple example is the one where you put all layers for a video encoding in a single SSRC. In such a stream you loose a single RTP packet between the transmitting end-point and the SFU. Now the SFU is only forwarding the base layer and not the enhancement layers. If base layer and enhancement layer share RTP stream, the SFU can't determine if the missing packet contains an base layer data or enhancement layer data. If the base layer and enhancement layer would be on different SSRC, the fact that there is a missing packet on the enhancement layer RTP stream means that the SFU can ignore that as it anyway are not forwarding it. This same argument can be applied between media sources. So how you map your application level structures onto RTP do matter for the resulting performance of RTP. Putting all on a single SSRC is not a path to good transport performance. Cheers Magnus Westerlund ------=_NextPart_000_004B_01D6883E.2B29D500 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVdjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGBzCCA++gAwIBAgIQ C0ZtzXB7bjBlrrZreXF57TANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMjE1 MDcyMjIzWhcNMjAxMjE1MDcyMjIyWjBwMREwDwYDVQQKDAhFcmljc3NvbjEaMBgGA1UEAwwRTWFn bnVzIFdlc3Rlcmx1bmQxLTArBgkqhkiG9w0BCQEWHm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29u LmNvbTEQMA4GA1UEBRMHZXJhbXN3ZDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALCp R2bwd07JixA7T0ohRSgIe90tsAKbfpWqoOXl06qJ6p80/cpBBi9ncfZgU/tlmYiCsaOMNrIrFZdx BGE6l05HLabq+3DdvYCwvBd7SRxiNrFFaTvQMKVazflLhxFXrR7e4XcVvbmHdCySfEz+v8BpCHwB WmcZWVJ+/TtnhxJX4odYlSIk2Vy3BHtawSbc4VDUR1oDptr0JQyeLAqYoBhaucPl0kb4hEDJEGUb 8NQkJm9+UEvwv09+qIMyERw7gHZKEmolDmP0tnS6eB5MLzjoPrQA6Wh5K23ZnZ4yhq2EpyYoJscN eKSboMS/1W9hHlXIKQH1VbLey5uDzj0SPPsCAwEAAaOCAcQwggHAMEgGA1UdHwRBMD8wPaA7oDmG N2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmww gYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNv bTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5s aW5kaXZpZHVhbGNhdjMuY2VyMCkGA1UdEQQiMCCBHm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29u LmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcDBAYI KwYBBQUHAwIwHQYDVR0OBBYEFOYr7oaVOdVuFIQQwVsH/F7FPN+2MB8GA1UdIwQYMBaAFBx7GZ6X nHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEAZ9BSrpIN NFDf3PxEqcUiGmE67HfJYhxzLuay6TgTTmnKRjQTBjYFAw7eEIoYaEEd3L4WFwqwDOfTU78NBzZY Kh2aBHlWO2JySWJyVwwi1H5CuQ59vBN0K88pJBeoIlDlw8hfZoVmG0gJCcsdGI9F3PHp98GDcqBW BKo5SrWa3VdKXIBcxHl1S0vA1q80su/in1LQzhIjOh98zt57KvvigZrDokipFp+KGBEWYOShJRAB 4rPWr/tyiGhD5zgLfEEVkaRXxmeHfPRdeqhbxJbqeZ+5fOuBasZwtn64g6OIS0GOhDWjmmCIoV4W 5dlGMQBg5PPWiZv0uaWMqu8M5viityHFJetK5nPEiZbekFysNMFxDhNTLm2rmCjLGndrPIw/qxJF 6fmoE0ZfrHs1mkcRwacblCg3ejIcA4oN0mYtaj+w/w7OFfiSyI41CXNuZfbbzBgvfpaiND/rzCN2 cq6LtDTX2+ebi0GqtfDvuwWfCr+47xXcWMlIG8UNEjxIsocpXCxwJiXiwkGomR5gkRAZAiykn9Du JRNk61c3Tg9/MI87kNu1N1HXVQg/REN7Re6OhFYacSSVJQesXv9lFsMuGZWu9XSi1IWpHVazeWm8 8ahVr8zgE/ZwWth82FQbaW3Luihoe9mCfjO/X2vYiJHEAoFJ8N4CAHlnf/5+GG2NkIQwggbCMIIE qqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlh U29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloX DTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIIC CgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5no rG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3 Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05ZrJldk UgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmbNJ7o58IZ YzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PVtO57HBKH MgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBsbpWIXwM6 kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUOxSqw1wup 5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT9rOdgdgS 3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx5Yd1c5Gs xuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9v Y3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnku dHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQI MAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6 Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6 aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNy bDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQW BBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjAN BgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUB D0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr 0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9 jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBdK/aj dbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0rI0RoGzIC fsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+i5CCKEZc dAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GITb/i7IBd Loo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5mdZ+RzPTo mgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeCaPKkveBJ zqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQC0ZtzXB7bjBl rrZreXF57TAJBgUrDgMCGgUAoIIBfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0yMDA5MTExMTE5MjRaMCMGCSqGSIb3DQEJBDEWBBSJbNlOQPaaY+OSIHNF1J6BZKU/ kzBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQC0ZtzXB7bjBl rrZreXF57TBsBgsqhkiG9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5 cXntMA0GCSqGSIb3DQEBAQUABIIBABZOA4YCQJBrRZ9RD0Mi+Pa2tserZEfB/2HwY4FR7IzIJXg+ uoI/OacJN2ujd1jcHE4a8n+4yMi9Eo8fcYAoeUAH5Sqd5TeqeFzgNmyG/ZSkTlLxMFY76j0Zzqhj fvDufPCdVEFxR4S9biojhawY5SqHtEnbzrb231qQ0hK5PPqakWjnsL6eOSWJWWzbZkBh8zrd34rd K8L7t4j8R85hyuq/h39diwTLAzSGCc+0UDSt5B/IPX1hLJCPBLcixILlv5iBPWuvmDLYSx48PAtq eTCdLo1wgXJ9G0Jhrga83qg70C/7JG1/AQAcIsc7U8n8eLwOhLP0X5IkMyhgeaeU75wAAAAAAAA= ------=_NextPart_000_004B_01D6883E.2B29D500-- From nobody Fri Sep 11 08:32:24 2020 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 64F2B3A1224; Fri, 11 Sep 2020 08:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.948, 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 E05Z0A1_maZI; Fri, 11 Sep 2020 08:32:13 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 8D8003A11DF; Fri, 11 Sep 2020 08:32:12 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id c18so11890724wrm.9; Fri, 11 Sep 2020 08:32:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=JuN1ckv9tmyjnAJn5sxuoB9jWH+nbfAB5vXruK38uSk=; b=c0zeEMVvFOysUoXzdUFxSbgdTkwvr2z+LL414tbARkPk9N+M+eTw+2IxRxauxKvu86 qzttmqYEnZaF+ggU/guZPj/tbP5hk3ty+MVuKJy0XG2hFA7lUx6uMCwZkD2tW26Ymz+i YhlMwa3rKX69itdPHS6X6LymdyYT5JLjGH3yXFtky5Osw4QaLyyMEz6c6Crmj1xR/Od5 v8boafywC3eixO/0FR9ziNNXBs9xnH77DzkBF706Xy366WlDkYP/gN3xb9JQWRAkULp3 kZU54WeUCaA0eGs3szTg3GXcqIHLLtjmN07FnufggqnMXC/URkhz+v339dahTSF8kTxc xceQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=JuN1ckv9tmyjnAJn5sxuoB9jWH+nbfAB5vXruK38uSk=; b=tSRGQrNbaKskPxJHjaeHqWpa+o5p/jX6xSukzKijV8RpjTd9N56MasRa1T/+nQWwEx g+Yp4cS7P92S8tZBkuVPRByHhG7pELTFCNzyzTPrDLVQJ+0MfZLkXB2FZNyYHw+LUECY 9pMvJSWOhhl7NDPPd+NUVIFP+L40yVHWZGuGDNidyUZp3oK1Ec3767y8J6MIN7w34kYk simu/HQ6wYqKtfM7ZHOq0JUEum/fi26TlfNoQkVgOydtJokNJ9TBs3qOVlRK1L5h+Fx0 iQD1SjHuJQiu5pfnEMlcVrNWT+UL6hvPbl8nVf+a62p7NxU+bpM3lP9Q6Hj/+Ph8qWjE ZNuQ== X-Gm-Message-State: AOAM530/JxMeXl9FxLm8b5PyqELfEywwuqrQ8FzXeVH7XewalU5czPdj prVxhexDGS7FbJN/Ttf6tbuPgm/SFwb2bDtZ X-Google-Smtp-Source: ABdhPJz723uCYagtjNtldVB5mccmc+BdpG2SNiUVbb0rw/CVxmkG5c+nwfKrDDWu3mcf0KoCHkI/og== X-Received: by 2002:a05:6000:1282:: with SMTP id f2mr2790848wrx.251.1599838329921; Fri, 11 Sep 2020 08:32:09 -0700 (PDT) Received: from [192.168.0.11] (79.108.125.160.dyn.user.ono.com. [79.108.125.160]) by smtp.googlemail.com with ESMTPSA id k6sm5122933wmf.30.2020.09.11.08.32.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Sep 2020 08:32:09 -0700 (PDT) To: Magnus Westerlund , "magnus.westerlund=40ericsson.com@dmarc.ietf.org" , "sergio.garcia.murillo@cosmosoftware.io" , "rlb@ipv.sx" Cc: "sframe-chairs@ietf.org" , "dispatch@ietf.org" , "iesg@ietf.org" , "sframe@ietf.org" References: <159949693494.2875.16993532753477402380@ietfa.amsl.com> <5c6c96621b29ebf4b1f84e53ae3a414c9d0ec3a5.camel@ericsson.com> <05085c6c-0c30-a407-8f41-b6c9be8100bc@gmail.com> From: Sergio Garcia Murillo Message-ID: Date: Fri, 11 Sep 2020 17:32:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Sframe] [dispatch] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2020 15:32:15 -0000 On 11/09/2020 13:19, Magnus Westerlund wrote: > Hi, > >>> So do I assume correctly that the idea is that the application layer >>> using SFRAME if it haves multiple independent or sets of dependent >>> streams there will be no support for that aspect in SFRAME layer? >>> Instead it is up to the application to put such information to either >>> put it inside the encapsualted part of the SFRAME or map it to the >>> lower transport layer, like to RTP SSRCs and extension information. >> >> If i understood you correctly, SFrame is kind of agnostic to the media >> streams. Currently it has a single global frame counter for all the > transport, so >> the number of streams/dependency between them is not known/needed >> by SFrame. > Yes, and when using a multi-stream application with layered encoding being > protected by SFRAME and transported over RTP with repair functions the high > layer application will need to have a model for how it maps individual > SFRAMEs to RTP layer functions to enable them to do their work. You get a > very limited functionality if in an SFU system tries to send all over a > single RTP SSRC. So this becomes a discussion in the RTP Payload format > context when carrying SFRAMEs. I don't really understand your point, let's put an example vp9 svc. Chrome will encode each picture from the video stream and pass it to the vp9 svc encoder. The encoder will produce n-frames (one per spatial layer) for a given picture. Chrome will get each frame with its metadata (spatial/layer id + layer structure info + previous frame dependencies + future frame depencies) and pass it over to the insertable streams. The payload will go to javascript, in where SFRAME will encrypt it and returned as a binary blob. The browser will get the binary blob, packetize it in several rtp packets according to the new packetization format and add the metadata as a header extension. Is this process what you are describing or is there anything missing? > >> >>>> However, if the encrypted output is going to be transmitted over RTP >>>> using a new packetization format, we need to address how to negotiate >>>> that in the SDP. >>> Good >>> >>>> Note that this new packetization format will not only be alid for >>>> transporting encrypted frames (SFrame or not) but even any other >>>> audio/video frames. >>> I understand the potential exists. However, the recommendation for RTP >>> has been to try to consider Application Level Framing. In the case of >>> SFRAME that consideration moves up above SFRAME in the choice of how >>> data is split into SFRAMEs. However, having an RTP paylaod format for >>> SFRAME, then that should carry SFRAMEs. If you starts putting in other >>> binary objects into it, then you create a new demultiplexing point for >>> format between the RTP payload format and the SFRAME processing. That >> appears unmotivated. >> >> >> Note that SFRAME is not the only encryption possible with w3c insertable >> streams, it is up to the application to define its own crypto if they > want. So >> the payload must be able to transport non-SFRAME opaque blobs. > So I would consider this a misuse of the RTP payload format. The media type > will be for SFRAMEs. I understand that you might not be able to prevent this > in WebRTC. However, from an interoperability point of view you will be > stating that this is SFRAMEs. RTP will not be able to tell a difference. But > I don't see that this is will explicitly support carrying other things than > SFRAME. Because that means bringing in other consideration including the > security model for the E2E usage. Not sure if ignoring the reality on how the packetization format is going to be used within insertable streams is a good idea. >>> Should the RTP payload format aspect of the charter be more explicit >>> in that it needs to disucss the general model of how to use SFRAME and >>> how an application can use the facilities of RTP to get good >>> performance from RTP mechanism like FEC and retransmission? >> >> I don't think so, RTX and FEC frames MUST not be modified/affected by >> SFRAME/the new packetization format, so they work out of the box. We can >> be explicit about that in the chapter as a requirement. >> > So I am not saying that RTX or FEC shall be modified. What I am saying is > that the SFRAME payload format should discuss the impact on the performance > of these functions depending on how you structure the SFRAMES across SSRCs. > The most simple example is the one where you put all layers for a video > encoding in a single SSRC. In such a stream you loose a single RTP packet > between the transmitting end-point and the SFU. Now the SFU is only > forwarding the base layer and not the enhancement layers. If base layer and > enhancement layer share RTP stream, the SFU can't determine if the missing > packet contains an base layer data or enhancement layer data. If the base > layer and enhancement layer would be on different SSRC, the fact that there > is a missing packet on the enhancement layer RTP stream means that the SFU > can ignore that as it anyway are not forwarding it. This same argument can > be applied between media sources. So how you map your application level > structures onto RTP do matter for the resulting performance of RTP. Putting > all on a single SSRC is not a path to good transport performance. But that is already the case for SVC codecs, so there is nothing new to specify in that regard. Best regards Sergio From nobody Mon Sep 14 00:30:08 2020 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 8A0AB3A0CDD; Mon, 14 Sep 2020 00:30:04 -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=[DKIMWL_WL_HIGH=-1.695, 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=unavailable 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 GELlAJva27o0; Mon, 14 Sep 2020 00:30:03 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150085.outbound.protection.outlook.com [40.107.15.85]) (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 90C943A0CDA; Mon, 14 Sep 2020 00:30:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LftmLB+iH6u/59Z0q/smXYhZcc2utjswg2iDgYM6UU2yGuA1szjgfsJgaFmfy2xn8SNHVzm97UYmA+Gz5p1Y9+rXH6LOTW4JsIY9jrm04gUnhCmzyr7gJnNv2hKiXU9Ze9M5eC92jOr1Forn0QaJAwShDi+WfyPpxh059wsSVq9CRCIRME7ohYTMkEncVPiFFkv2DsLbOPdeg/Dy4Tt3NmSSp4wGjFAcdbQAYdm1RuCQDno4bYJwHXFCLGYzjZfTWj9+SBMiN/4EJopRQufX+AmtIdr5wFrzE6t34j/qXCWO/4p+6WNLimoLDAuaZepzjbFo73JYVjK86/uH6ec9gQ== 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=uEwnv1PlCekOtaAbmT4ZMlmKB3zzlJKnd052xSfP7Vk=; b=O9y2yLVXOhiwEwGECUccTwtkRcp27/4ip7vPGUJxejC2loITLhEFP7f6dHn4oyVoPMFWGfRM1KsaBQIqRF8zeY/MaZyhWySyFTntjJHtWNfRG+9PjZGkCVyzoBQooJRIDXsn7J8/zRb9pjd3nUbYBoA8Wvh/GizLKqA3LINtNS+Kypazn22kClbsvnoZ+8mZcHE3MVKT+UPLew2l1fCxN1hcynhsaGOY78ZgfoVqBNPtCA22JuFPKHxfcP+Ttm+0t4BOA5/PLKIWzJgQvrQcaPcnOBbOH1udIijpjvVbhFQTPwGJCApBdZToTspGD/le8FhQJqr+QzkbimmR7r8j9g== 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=uEwnv1PlCekOtaAbmT4ZMlmKB3zzlJKnd052xSfP7Vk=; b=Msglxsl0xwZUfCOucD0Ci18sJOkvn0XLKoqm57IVyFryHfN4PmZB7CYTIuPxPMWwBSTyZp9UoqnW9t2J8tGsTHQDGl6zsvEawSVmi5+L+PRI4QTT0w2l14yoY1C0km1A2NVb4zoeMN++0JpyUDUhrI5TsJevm/b2pxYIVQmrAhY= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR0701MB2460.eurprd07.prod.outlook.com (2603:10a6:3:70::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.5; Mon, 14 Sep 2020 07:29:55 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::c98a:9a0c:1eea:3fdc]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::c98a:9a0c:1eea:3fdc%6]) with mapi id 15.20.3391.009; Mon, 14 Sep 2020 07:29:55 +0000 From: Magnus Westerlund To: "rlb@ipv.sx" , "magnus.westerlund=40ericsson.com@dmarc.ietf.org" , "sergio.garcia.murillo@cosmosoftware.io" , "sergio.garcia.murillo@gmail.com" CC: "dispatch@ietf.org" , "iesg@ietf.org" , "sframe-chairs@ietf.org" , "sframe@ietf.org" Thread-Topic: [dispatch] [Sframe] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) Thread-Index: AQHWhTXfuLaYkFC4LEWqC8j5AGiLAKlh8DkAgAASwICAALgzgIAAV8mAgAAoYICAAA/A0IAAS+mAgAQwQoA= Date: Mon, 14 Sep 2020 07:29:54 +0000 Message-ID: <49b13e5efa0b2ac0a7b09842dbce8793dfcf6667.camel@ericsson.com> References: <159949693494.2875.16993532753477402380@ietfa.amsl.com> <5c6c96621b29ebf4b1f84e53ae3a414c9d0ec3a5.camel@ericsson.com> <05085c6c-0c30-a407-8f41-b6c9be8100bc@gmail.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2 authentication-results: ipv.sx; dkim=none (message not signed) header.d=none;ipv.sx; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [158.174.116.90] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 22940179-27f9-4760-076f-08d8587ff9f5 x-ms-traffictypediagnostic: HE1PR0701MB2460: 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: WdiZGDVNVm7Jwll6rhk4MxGtpvVzuDbdyPr64SZ+w0MSD6efwrrLlJPABmcU02KoMeRDxG8ZQJIvgNU2KJbwZWeoNtz0yLsUQUcDlC5NtKgetfCepFD4mmeExVX1/Ziptsu1N4zd8rrRzEuzqB2uq+cUBD1oFq+vryzgB2mtQTuFWK03YDtILkcVK2D80h6fEIVJ+6bGEIQGRmkERJmeas0sijj9hmaA+pIZmFfTnwX5ghMGEIewDuIFQp1ZKqJVCdvhGN5zJC8rp8rzoa9EZtkAhNYmyjN0PDx4TOu/BrwoKyVFbfQLXVP2BE289XYqCn8OvEIn97E6RP13Mpn0O+lubAVi8SZV1qx7TsdRCHKoJf7nJD2bxphwHlJrOibFpNkI/r+5hYJmhOz/QLMOFbo9ZukaVKMB/LLm4SaOHAQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(376002)(346002)(136003)(39860400002)(366004)(83380400001)(8676002)(76116006)(4326008)(26005)(66476007)(64756008)(66446008)(66946007)(66556008)(110136005)(54906003)(2906002)(36756003)(44832011)(66574015)(2616005)(6512007)(86362001)(5660300002)(6486002)(8936002)(316002)(53546011)(6506007)(508600001)(186003)(71200400001)(99106002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: BEvh7jr25Htzi9xBQOsOho5lEQjOFBNH2M03PggWSwLBr7blWXS4SAyn9v2kD6+M+7Gy6aztUJSEnXQszzFYAxCeNyvCVj0/bXxOumGirbPnhLXm9mlI355gCVg3qpsIrA9GjC3aQGHpg0zBX9NkcwyjTVLHG8y3pWz+lLJHMii7cEyY6P+2vA6j0C5tcmzJCvyC0aFd2yCchM/zsU4h6vq02dIlk9II/g3YaskbDHQk/3pVws/DgFwxTcWb5SVQgBDEvAOz6haIuluWJiDng8RK8CY3jVRvJbSrNn4v6ZacRRrdIDKDei/dVdTWK87uQRcRqYAAW1if+Dm2ae06PZG/r+SXjcgY8K2QOQt2+/KnlFCrTfE32YEUkFt0fy+IMWNCl6YD4ocS2TFsSbAaMsG7RP6VQqiEfaUPs5tAV/wpFh5AMj87nedfCSXY9NGRfhjL0RS8PPM+lJvy7jbvOC+w37zJxG/Vdv3VdW2JyKPmCxwLETPndv0dFVQvt7Pj6yXiIN+MT/QyVOMa7MkrvjyjETpHB/h5dipDyTOqHe5CZgwrZB5yYlffV1cgpD8l7SItdM2646Pf9BBwB6/cMzjA7uMRsV3bwzqVo+D7bmE+J82tuVCnB5Vt99UHTCSqYd6J8s8rPaHMMx4jw9l6Vw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <5E11A349B969E74C8A49D84EE4752C9E@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 22940179-27f9-4760-076f-08d8587ff9f5 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2020 07:29:54.9171 (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: dbp1aQRlN7XJA7z9mFsTLBzNfk0tkoNl7gutCzZCh7R6nsvBu24F45g69YrWL7DH4ndx/GZxqdL5DD7/nekEr+gRR2gKRqIMihWNn/5Zj5U= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2460 Archived-At: Subject: Re: [Sframe] [dispatch] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2020 07:30:04 -0000 SGksDQoNClBsZWFzZSBzZWUgaW5saW5lDQoNCk9uIEZyaSwgMjAyMC0wOS0xMSBhdCAxNzozMiAr MDIwMCwgU2VyZ2lvIEdhcmNpYSBNdXJpbGxvIHdyb3RlOg0KPiBPbiAxMS8wOS8yMDIwIDEzOjE5 LCBNYWdudXMgV2VzdGVybHVuZCB3cm90ZToNCj4gPiBIaSwNCj4gPiANCj4gPiA+ID4gU28gZG8g SSBhc3N1bWUgY29ycmVjdGx5IHRoYXQgdGhlIGlkZWEgaXMgdGhhdCB0aGUgYXBwbGljYXRpb24g bGF5ZXINCj4gPiA+ID4gdXNpbmcgU0ZSQU1FIGlmIGl0IGhhdmVzIG11bHRpcGxlIGluZGVwZW5k ZW50IG9yIHNldHMgb2YgZGVwZW5kZW50DQo+ID4gPiA+IHN0cmVhbXMgdGhlcmUgd2lsbCBiZSBu byBzdXBwb3J0IGZvciB0aGF0IGFzcGVjdCBpbiBTRlJBTUUgbGF5ZXI/DQo+ID4gPiA+IEluc3Rl YWQgaXQgaXMgdXAgdG8gdGhlIGFwcGxpY2F0aW9uIHRvIHB1dCBzdWNoIGluZm9ybWF0aW9uIHRv IGVpdGhlcg0KPiA+ID4gPiBwdXQgaXQgaW5zaWRlIHRoZSBlbmNhcHN1YWx0ZWQgcGFydCBvZiB0 aGUgU0ZSQU1FIG9yIG1hcCBpdCB0byB0aGUNCj4gPiA+ID4gbG93ZXIgdHJhbnNwb3J0IGxheWVy LCBsaWtlIHRvIFJUUCBTU1JDcyBhbmQgZXh0ZW5zaW9uIGluZm9ybWF0aW9uLg0KPiA+ID4gDQo+ ID4gPiBJZiBpIHVuZGVyc3Rvb2QgeW91IGNvcnJlY3RseSwgU0ZyYW1lIGlzIGtpbmQgb2YgYWdu b3N0aWMgdG8gdGhlIG1lZGlhDQo+ID4gPiBzdHJlYW1zLiBDdXJyZW50bHkgaXQgaGFzIGEgc2lu Z2xlIGdsb2JhbCBmcmFtZSBjb3VudGVyIGZvciBhbGwgdGhlDQo+ID4gDQo+ID4gdHJhbnNwb3J0 LCBzbw0KPiA+ID4gdGhlIG51bWJlciBvZiBzdHJlYW1zL2RlcGVuZGVuY3kgYmV0d2VlbiB0aGVt IGlzIG5vdCBrbm93bi9uZWVkZWQNCj4gPiA+IGJ5IFNGcmFtZS4NCj4gPiANCj4gPiBZZXMsIGFu ZCB3aGVuIHVzaW5nIGEgbXVsdGktc3RyZWFtIGFwcGxpY2F0aW9uIHdpdGggbGF5ZXJlZCBlbmNv ZGluZyBiZWluZw0KPiA+IHByb3RlY3RlZCBieSBTRlJBTUUgYW5kIHRyYW5zcG9ydGVkIG92ZXIg UlRQIHdpdGggcmVwYWlyIGZ1bmN0aW9ucyB0aGUgaGlnaA0KPiA+IGxheWVyIGFwcGxpY2F0aW9u IHdpbGwgbmVlZCB0byBoYXZlIGEgbW9kZWwgZm9yIGhvdyBpdCBtYXBzIGluZGl2aWR1YWwNCj4g PiBTRlJBTUVzIHRvIFJUUCBsYXllciBmdW5jdGlvbnMgdG8gZW5hYmxlIHRoZW0gdG8gZG8gdGhl aXIgd29yay4gWW91IGdldCBhDQo+ID4gdmVyeSBsaW1pdGVkIGZ1bmN0aW9uYWxpdHkgaWYgaW4g YW4gU0ZVIHN5c3RlbSB0cmllcyB0byBzZW5kIGFsbCBvdmVyIGENCj4gPiBzaW5nbGUgUlRQIFNT UkMuIFNvIHRoaXMgYmVjb21lcyBhIGRpc2N1c3Npb24gaW4gdGhlIFJUUCBQYXlsb2FkIGZvcm1h dA0KPiA+IGNvbnRleHQgd2hlbiBjYXJyeWluZyBTRlJBTUVzLg0KPiANCj4gDQo+IEkgZG9uJ3Qg cmVhbGx5IHVuZGVyc3RhbmQgeW91ciBwb2ludCwgbGV0J3MgcHV0IGFuIGV4YW1wbGUgdnA5IHN2 Yy4NCj4gDQo+IENocm9tZSB3aWxsIGVuY29kZSBlYWNoIHBpY3R1cmUgZnJvbSB0aGUgdmlkZW8g c3RyZWFtIGFuZCBwYXNzIGl0IHRvIHRoZSANCj4gdnA5IHN2YyBlbmNvZGVyLiBUaGUgZW5jb2Rl ciB3aWxsIHByb2R1Y2Ugbi1mcmFtZXMgKG9uZSBwZXIgc3BhdGlhbCANCj4gbGF5ZXIpIGZvciBh IGdpdmVuIHBpY3R1cmUuDQo+IA0KPiBDaHJvbWUgd2lsbCBnZXQgZWFjaCBmcmFtZSB3aXRoIGl0 cyBtZXRhZGF0YSAoc3BhdGlhbC9sYXllciBpZCArIGxheWVyIA0KPiBzdHJ1Y3R1cmUgaW5mbyAr IHByZXZpb3VzIGZyYW1lIGRlcGVuZGVuY2llcyArIGZ1dHVyZSBmcmFtZSBkZXBlbmNpZXMpIA0K PiBhbmQgcGFzcyBpdCBvdmVyIHRvIHRoZSBpbnNlcnRhYmxlIHN0cmVhbXMuDQo+IA0KPiBUaGUg cGF5bG9hZCB3aWxsIGdvIHRvIGphdmFzY3JpcHQsIGluIHdoZXJlIFNGUkFNRSB3aWxsIGVuY3J5 cHQgaXQgYW5kIA0KPiByZXR1cm5lZCBhcyBhIGJpbmFyeSBibG9iLg0KPiANCj4gVGhlIGJyb3dz ZXIgd2lsbCBnZXQgdGhlIGJpbmFyeSBibG9iLCBwYWNrZXRpemUgaXQgaW4gc2V2ZXJhbCBydHAg DQo+IHBhY2tldHMgYWNjb3JkaW5nIHRvIHRoZSBuZXcgcGFja2V0aXphdGlvbiBmb3JtYXQgYW5k IGFkZCB0aGUgbWV0YWRhdGEgDQo+IGFzIGEgaGVhZGVyIGV4dGVuc2lvbi4NCj4gDQo+IElzIHRo aXMgcHJvY2VzcyB3aGF0IHlvdSBhcmUgZGVzY3JpYmluZyBvciBpcyB0aGVyZSBhbnl0aGluZyBt aXNzaW5nPw0KPiANCg0KVGhlbiB0aGUgY2xpZW50IHdpbGwgc2VuZCB0aGVzZSBSVFAgcGFja2V0 cyB0byBhbiBTRlUgdGhhdCB3aWxsIG5lZWQgdG8gbWFrZQ0KZGVjaXNpb24gb24gd2hpY2ggb2Yg dGhlIHBhY2tldHMgdG8gZm9yd2FyZCBmb3Igd2hpY2ggbGF5ZXJzIHRvIGEgcGFydGljdWxhcg0K cmVjZWl2ZXIuIFRvIGJlIGFibGUgdG8gZG8gdGhpcyB0aGVyZSBhcmUgZmlyc3QgdGhlIGFzcGVj dCBvZiB0aGF0IHRoZSBtZXRhIGRhdGENCm5lZWRzIHRvIGJlIGluY2x1ZGVkIHNvIHRoYXQgdGhl IFNGVSBjYW4gbWFrZSBkZWNpc2lvbiBiYXNlZCBvbiB0aGUgcGFja2V0cyBpdA0KcmVjaWV2ZXMu IEluIFJUUCBjb250ZXh0IHRoaXMgbGlrZWx5IGFyZSBhIG1vcmUgZ2VuZXJpYyBzdHJ1Y3R1cmUg bGlrZSB0aGUgUlRQDQpoZWFkZXIgZXh0ZW5zaW9uIGZvciBGcmFtZSBtYXJraW5nIChkcmFmdC1p ZXRmLWF2dGV4dC1mcmFtZW1hcmtpbmcpLiANCg0KRm9yIHBhY2tldCBpdCBkb2Vzbid0IHJlY2Vp dmUgaXQgbGFja3MgdGhlIG1ldGEgZGF0YS4gVGh1cywgZm9yIGEgbW9yZSBlZmZpY2llbnQNCnJl cGFpciBvZiBwYWNrZXRzIHRoYXQgYXJlIG1pc3NpbmcgYW5kIHRvIHJlcGFpciBvbmx5IHBhY2tl dHMgdGhhdCB0aGUgU0ZVDQphY3R1YWxseSBuZWVkcywgdGhlbiB5b3UgYWN0dWFsbHkgaGF2ZSB0 byBtYXAgdGhlIGxheWVyZWQgc3RydWN0dXJlIGludG8gUlRQDQpsZXZlbCBzdHJ1Y3R1cmVzIHNv IHRoYXQgdGhlIFNGVSBjYW4gZGV0ZXJtaW5lIHRoYXQgdGhlIG1pc3NpbmcgcGFja2V0IGJlbG9u Z3MNCnRvIGEgbGF5ZXIgdGhhdCBpdCBhY3R1YWxseSBpbnRlbmRzIHRvIGZvcndhcmQuIFB1dHRp bmcgZXZlcnl0aGluZyBpbiBhIHNpbmdsZQ0KU1NSQyByZXF1aXJlcyB0aGUgU0ZVIHRvIHJlcGFp ciBhbGwgbG9zc2VzIGluZGVwZW5kZW50IG9mIGl0IG5lZWRpbmcgdGhlIHBhY2tldA0Kb3Igbm90 LiANCg0KQSBldmVuIG1vcmUgZXh0cmVtZSBleGFtcGxlIGlzIGlmIHRoZSBjbGllbnQgaGFzIDMg dmlkZW8gY2FtZXJhcyBhbmQgcHJvZHVjZSAzDQp2aWRlbyBlbmNvZGluZ3MuIEluIHRoZSBTRlJB TUUgY29udGV4dCBpdCBpcyBwb3NzaWJsZSB0byB0YWtlIHRoZSB2aWRlbyBmcmFtZXMNCmZyb20g YWxsIHRoZXNlIHRocmVlZSBlbmNvZGluZ3MgYW5kIHB1dCB0aGVtIGluIGEgc2luZ2xlIFJUUCBz dHJlYW0gKFNTUkMpIHdpdGgNClNGUkFNRXMgZnJvbSB0aGF0IGVuZC1wb2ludC4gSG93ZXZlciwg dGhhdCB3b3VsZCBmb3JjZSB5b3VyIG1ldGEgZGF0YSB0byBjb250YWluDQphbHNvIHNvdXJjZSBp ZGVudGlmaWNhdGlvbiByYXRoZXIgdGhhbiB0byB1c2luZyBkaWZmZXJlbnQgU1NSQ3MuIFB1dHRp bmcNCm11bHRpcGxlIGVuY29kaW5nIG9uIGFuIHNpbmdsZSBSVFAgc3RyZWFtIHdvdWxkIGRlcHJp dmUgdGhlIFNGVSBvZiB0aGUNCnBvc3NpYmlsaXR5IHRvIGRvIHJhdGUgY29udHJvbCBwZXIgZW5j b2RpbmcgKFJGQyA1MTA0IC0gVE1NQlIpIGFzIHdlbGwgYXMgcGF1c2UNCnN0cmVhbXMgaXQgZG9l c24ndCBmb3J3YXJkIGF0IGFsbCAoUkZDIDc3MjggLSBTdHJlYW0gUEFVU0UpIGJlY2F1c2UgYWxs IHRoZQ0KZXhpc3RpbmcgUlRQIG1lY2hhbmlzbSB0aGF0IGFyZSBpbmNsdWRlZCBpbiBXZWJSVEMg d29ya3Mgb24gdGhlIFJUUCBzdHJlYW1zLCBub3QNCnN1Yi1zdHJlYW1zIHRoYXQgZG9lc24ndCBo YXZlIGFuIGlkZW50aWZpZXIgaW4gdGhlIFJUUCBsYXllci4gSW4gYWRkaXRpb24gdG8NCmhhdmlu ZyB0byByZXBhaXIgYW55IGxvc3MgZm9yIHRoZSBhZ2dyZWdhdGVkIHN0cmVhbSBvZiB0aGUgdGhy ZWUgZW5jb2RpbmdzLg0KDQo+IA0KPiA+IA0KPiA+ID4gDQo+ID4gPiA+ID4gSG93ZXZlciwgaWYg dGhlIGVuY3J5cHRlZCBvdXRwdXQgaXMgZ29pbmcgdG8gYmUgdHJhbnNtaXR0ZWQgb3ZlciBSVFAN Cj4gPiA+ID4gPiB1c2luZyBhIG5ldyBwYWNrZXRpemF0aW9uIGZvcm1hdCwgd2UgbmVlZCB0byBh ZGRyZXNzIGhvdyB0byBuZWdvdGlhdGUNCj4gPiA+ID4gPiB0aGF0IGluIHRoZSBTRFAuDQo+ID4g PiA+IA0KPiA+ID4gPiBHb29kDQo+ID4gPiA+IA0KPiA+ID4gPiA+IE5vdGUgdGhhdCB0aGlzIG5l dyBwYWNrZXRpemF0aW9uIGZvcm1hdCB3aWxsIG5vdCBvbmx5IGJlIGFsaWQgZm9yDQo+ID4gPiA+ ID4gdHJhbnNwb3J0aW5nIGVuY3J5cHRlZCBmcmFtZXMgKFNGcmFtZSBvciBub3QpIGJ1dCBldmVu IGFueSBvdGhlcg0KPiA+ID4gPiA+IGF1ZGlvL3ZpZGVvIGZyYW1lcy4NCj4gPiA+ID4gDQo+ID4g PiA+IEkgdW5kZXJzdGFuZCB0aGUgcG90ZW50aWFsIGV4aXN0cy4gSG93ZXZlciwgdGhlIHJlY29t bWVuZGF0aW9uIGZvciBSVFANCj4gPiA+ID4gaGFzIGJlZW4gdG8gdHJ5IHRvIGNvbnNpZGVyIEFw cGxpY2F0aW9uIExldmVsIEZyYW1pbmcuIEluIHRoZSBjYXNlIG9mDQo+ID4gPiA+IFNGUkFNRSB0 aGF0IGNvbnNpZGVyYXRpb24gbW92ZXMgdXAgYWJvdmUgU0ZSQU1FIGluIHRoZSBjaG9pY2Ugb2Yg aG93DQo+ID4gPiA+IGRhdGEgaXMgc3BsaXQgaW50byBTRlJBTUVzLiBIb3dldmVyLCBoYXZpbmcg YW4gUlRQIHBheWxhb2QgZm9ybWF0IGZvcg0KPiA+ID4gPiBTRlJBTUUsIHRoZW4gdGhhdCBzaG91 bGQgY2FycnkgU0ZSQU1Fcy4gSWYgeW91IHN0YXJ0cyBwdXR0aW5nIGluIG90aGVyDQo+ID4gPiA+ IGJpbmFyeSBvYmplY3RzIGludG8gaXQsIHRoZW4geW91IGNyZWF0ZSBhIG5ldyBkZW11bHRpcGxl eGluZyBwb2ludCBmb3INCj4gPiA+ID4gZm9ybWF0IGJldHdlZW4gdGhlIFJUUCBwYXlsb2FkIGZv cm1hdCBhbmQgdGhlIFNGUkFNRSBwcm9jZXNzaW5nLiBUaGF0DQo+ID4gPiANCj4gPiA+IGFwcGVh cnMgdW5tb3RpdmF0ZWQuDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gTm90ZSB0aGF0IFNGUkFNRSBp cyBub3QgdGhlIG9ubHkgZW5jcnlwdGlvbiBwb3NzaWJsZSB3aXRoIHczYyBpbnNlcnRhYmxlDQo+ ID4gPiBzdHJlYW1zLCBpdCBpcyB1cCB0byB0aGUgYXBwbGljYXRpb24gdG8gZGVmaW5lIGl0cyBv d24gY3J5cHRvIGlmIHRoZXkNCj4gPiANCj4gPiB3YW50LiBTbw0KPiA+ID4gdGhlIHBheWxvYWQg bXVzdCBiZSBhYmxlIHRvIHRyYW5zcG9ydCBub24tU0ZSQU1FIG9wYXF1ZSBibG9icy4NCj4gPiAN Cj4gPiBTbyBJIHdvdWxkIGNvbnNpZGVyIHRoaXMgYSBtaXN1c2Ugb2YgdGhlIFJUUCBwYXlsb2Fk IGZvcm1hdC4gVGhlIG1lZGlhIHR5cGUNCj4gPiB3aWxsIGJlIGZvciBTRlJBTUVzLiBJIHVuZGVy c3RhbmQgdGhhdCB5b3UgbWlnaHQgbm90IGJlIGFibGUgdG8gcHJldmVudCB0aGlzDQo+ID4gaW4g V2ViUlRDLiBIb3dldmVyLCBmcm9tIGFuIGludGVyb3BlcmFiaWxpdHkgcG9pbnQgb2YgdmlldyB5 b3Ugd2lsbCBiZQ0KPiA+IHN0YXRpbmcgdGhhdCB0aGlzIGlzIFNGUkFNRXMuIFJUUCB3aWxsIG5v dCBiZSBhYmxlIHRvIHRlbGwgYSBkaWZmZXJlbmNlLiBCdXQNCj4gPiBJIGRvbid0IHNlZSB0aGF0 IHRoaXMgaXMgd2lsbCBleHBsaWNpdGx5IHN1cHBvcnQgY2Fycnlpbmcgb3RoZXIgdGhpbmdzIHRo YW4NCj4gPiBTRlJBTUUuIEJlY2F1c2UgdGhhdCBtZWFucyBicmluZ2luZyBpbiBvdGhlciBjb25z aWRlcmF0aW9uIGluY2x1ZGluZyB0aGUNCj4gPiBzZWN1cml0eSBtb2RlbCBmb3IgdGhlIEUyRSB1 c2FnZS4NCj4gDQo+IA0KPiBOb3Qgc3VyZSBpZiBpZ25vcmluZyB0aGUgcmVhbGl0eSBvbiBob3cg dGhlIHBhY2tldGl6YXRpb24gZm9ybWF0IGlzIA0KPiBnb2luZyB0byBiZSB1c2VkIHdpdGhpbiBp bnNlcnRhYmxlIHN0cmVhbXMgaXMgYSBnb29kIGlkZWEuDQoNCklmIHlvdSBhcmUgcGFzc2luZyBv dGhlciB0aGluZ3MgdGhhbiBTRlJBTUUgeW91IGFyZSBhbHNvIHNlbmRpbmcgdGhlbSB3aXRob3V0 DQplbmQtdG8tZW5kIHByb3RlY3Rpb24uIFdoeSBpcyB0aGlzIGhhcHBlbmluZywgaWYgdGhlIGlu Zm9ybWF0aW9uIHdhcyBpbnRlbmRlZA0KZm9yIHRoZSBTRlUsIHRoZW4gSSB0aGluayB3ZSBzaG91 bGQgaWRlbnRpZnkgaXQgYXMgc3VjaCwgcmF0aGVyIHRoYW4gaGF2aW5nIHRoZQ0KU0ZVIGhhdmUg dG8gaHVudCBmb3IgaXQuIElmIG5vdCwgd2h5IGFyZSB5b3Ugc2VuZGluZyBpdCBvdXRzaWRlIG9m IHRoZSBTRlJBTUUNCmVudmVsb3BlPyANCg0KPiANCj4gDQo+ID4gPiA+IFNob3VsZCB0aGUgUlRQ IHBheWxvYWQgZm9ybWF0IGFzcGVjdCBvZiB0aGUgY2hhcnRlciBiZSBtb3JlIGV4cGxpY2l0DQo+ ID4gPiA+IGluIHRoYXQgaXQgbmVlZHMgdG8gZGlzdWNzcyB0aGUgZ2VuZXJhbCBtb2RlbCBvZiBo b3cgdG8gdXNlIFNGUkFNRSBhbmQNCj4gPiA+ID4gaG93IGFuIGFwcGxpY2F0aW9uIGNhbiB1c2Ug dGhlIGZhY2lsaXRpZXMgb2YgUlRQIHRvIGdldCBnb29kDQo+ID4gPiA+IHBlcmZvcm1hbmNlIGZy b20gUlRQIG1lY2hhbmlzbSBsaWtlIEZFQyBhbmQgcmV0cmFuc21pc3Npb24/DQo+ID4gPiANCj4g PiA+IEkgZG9uJ3QgdGhpbmsgc28sIFJUWCBhbmQgRkVDIGZyYW1lcyBNVVNUIG5vdCBiZSBtb2Rp ZmllZC9hZmZlY3RlZCBieQ0KPiA+ID4gU0ZSQU1FL3RoZSBuZXcgcGFja2V0aXphdGlvbiBmb3Jt YXQsIHNvIHRoZXkgd29yayBvdXQgb2YgdGhlIGJveC4gV2UgY2FuDQo+ID4gPiBiZSBleHBsaWNp dCBhYm91dCB0aGF0IGluIHRoZSBjaGFwdGVyIGFzIGEgcmVxdWlyZW1lbnQuDQo+ID4gPiANCj4g PiANCj4gPiBTbyBJIGFtIG5vdCBzYXlpbmcgdGhhdCBSVFggb3IgRkVDIHNoYWxsIGJlIG1vZGlm aWVkLiBXaGF0IEkgYW0gc2F5aW5nIGlzDQo+ID4gdGhhdCB0aGUgU0ZSQU1FIHBheWxvYWQgZm9y bWF0IHNob3VsZCBkaXNjdXNzIHRoZSBpbXBhY3Qgb24gdGhlIHBlcmZvcm1hbmNlDQo+ID4gb2Yg dGhlc2UgZnVuY3Rpb25zIGRlcGVuZGluZyBvbiBob3cgeW91IHN0cnVjdHVyZSB0aGUgU0ZSQU1F UyBhY3Jvc3MgU1NSQ3MuDQo+ID4gVGhlIG1vc3Qgc2ltcGxlIGV4YW1wbGUgaXMgdGhlIG9uZSB3 aGVyZSB5b3UgcHV0IGFsbCBsYXllcnMgZm9yIGEgdmlkZW8NCj4gPiBlbmNvZGluZyBpbiBhIHNp bmdsZSBTU1JDLiBJbiBzdWNoIGEgc3RyZWFtIHlvdSBsb29zZSBhIHNpbmdsZSBSVFAgcGFja2V0 DQo+ID4gYmV0d2VlbiB0aGUgdHJhbnNtaXR0aW5nIGVuZC1wb2ludCBhbmQgdGhlIFNGVS4gTm93 IHRoZSBTRlUgaXMgb25seQ0KPiA+IGZvcndhcmRpbmcgdGhlIGJhc2UgbGF5ZXIgYW5kIG5vdCB0 aGUgZW5oYW5jZW1lbnQgbGF5ZXJzLiBJZiBiYXNlIGxheWVyIGFuZA0KPiA+IGVuaGFuY2VtZW50 IGxheWVyIHNoYXJlIFJUUCBzdHJlYW0sIHRoZSBTRlUgY2FuJ3QgZGV0ZXJtaW5lIGlmIHRoZSBt aXNzaW5nDQo+ID4gcGFja2V0IGNvbnRhaW5zIGFuIGJhc2UgbGF5ZXIgZGF0YSBvciBlbmhhbmNl bWVudCBsYXllciBkYXRhLiBJZiB0aGUgYmFzZQ0KPiA+IGxheWVyIGFuZCBlbmhhbmNlbWVudCBs YXllciB3b3VsZCBiZSBvbiBkaWZmZXJlbnQgU1NSQywgdGhlIGZhY3QgdGhhdCB0aGVyZQ0KPiA+ IGlzIGEgbWlzc2luZyBwYWNrZXQgb24gdGhlIGVuaGFuY2VtZW50IGxheWVyIFJUUCBzdHJlYW0g bWVhbnMgdGhhdCB0aGUgU0ZVDQo+ID4gY2FuIGlnbm9yZSB0aGF0IGFzIGl0IGFueXdheSBhcmUg bm90IGZvcndhcmRpbmcgaXQuIFRoaXMgc2FtZSBhcmd1bWVudCBjYW4NCj4gPiBiZSBhcHBsaWVk IGJldHdlZW4gbWVkaWEgc291cmNlcy4gU28gaG93IHlvdSBtYXAgeW91ciBhcHBsaWNhdGlvbiBs ZXZlbA0KPiA+IHN0cnVjdHVyZXMgb250byBSVFAgZG8gbWF0dGVyIGZvciB0aGUgcmVzdWx0aW5n IHBlcmZvcm1hbmNlIG9mIFJUUC4gUHV0dGluZw0KPiA+IGFsbCBvbiBhIHNpbmdsZSBTU1JDIGlz IG5vdCBhIHBhdGggdG8gZ29vZCB0cmFuc3BvcnQgcGVyZm9ybWFuY2UuDQo+IA0KPiANCj4gQnV0 IHRoYXQgaXMgYWxyZWFkeSB0aGUgY2FzZSBmb3IgU1ZDIGNvZGVjcywgc28gdGhlcmUgaXMgbm90 aGluZyBuZXcgdG8gDQo+IHNwZWNpZnkgaW4gdGhhdCByZWdhcmQuDQoNClNvIGZvciBTVkMgYW5k IG90aGVyIHNjYWxhYmxlIGNvZGVzIHRoZXJlIGV4aXN0cyBvcHRpb25zIGZvciBob3cgdG8gZG8g dGhpcy4gQW5kDQp3aGVyZSB5b3UgY2FuIHdyaXRlIGFuZCBSVFAgcGFja2V0aXplciBmb3IgU1ZD IHRoYXQgdGFrZXMgYmFzaWNhbHkgYSBtb2RlIGFuZCBhDQpsYXllciBzdHJ1Y3R1cmUgY29uZmln dXJhdGlvbiBhcyBpbnB1dCwgdGhhdCBpcyBub3QgcG9zc2libGUgZm9yIFNGUkFNRSBhcyB0aGF0 DQppbmZvcm1hdGlvbiBpcyBub3QgdmlzaWJsZSBpbiB0aGUgUlRQIHBheWxvYWQgaW5mb3JtYXRp b24uIEluc3RlYWQgaXQgbXVzdCBjb21lDQp3aXRoIGVhY2ggU0ZSQU1FIHRvIHBhY2tldGl6ZSBo b3cgdG8gbWFwIGl0IHRvIHRoZSBSVFAgbGF5ZXIuIA0KDQpUaHVzLCBpbiBteSB2aWV3IHRoZSBT RlJBTUUgUlRQIFBheWxvYWQgZm9ybWF0IG5lZWRzIHRvIGRpc2N1c3MgdGhlIGNvcmUgb2YNCnRo ZXNlIGlzc3VlcyB0byBtYWtlIGl0IGNsZWFyIHRvIHRoZSBhcHBsaWNhdGlvbiBib3RoIGl0cyBv cHRpb25zIGFzIHdlbGwgYXMNCnBvaW50IHRvIHRoZSBpbXBhY3Qgb2YgdGhvc2Ugb3B0aW9ucy4g DQoNCiANCkNoZWVycw0KDQpNYWdudXMgV2VzdGVybHVuZCANCg0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpO ZXR3b3JrcywgRXJpY3Nzb24gUmVzZWFyY2gNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkVyaWNzc29uIEFCICAg ICAgICAgICAgICAgICB8IFBob25lICArNDYgMTAgNzE0ODI4Nw0KVG9yc2hhbW5zZ2F0YW4gMjMg ICAgICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5DQpTRS0xNjQgODAgU3RvY2tob2xtLCBT d2VkZW4gfCBtYWlsdG86IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KDQoNCg== From nobody Mon Sep 14 02:39:38 2020 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 B10893A0D81; Mon, 14 Sep 2020 02:39:19 -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, 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=unavailable 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 uDcNNi3vDa12; Mon, 14 Sep 2020 02:39:18 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 86F1D3A0D7C; Mon, 14 Sep 2020 02:39:17 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id c18so17914639wrm.9; Mon, 14 Sep 2020 02:39:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=nCYNp39gdk8OY6IsNVveSNljSD3Em9HFvDgFPLDNcXY=; b=DVWTw6ei2FzV8rfrbD0vjLDZ0+O6t2nWAECGUV8YbvmrAfxKe/2rxm6GBD+P9E9DY4 fHEYtvpMDiDYLmIBm5Ow8RzSM7jmf0MXB9GzwzrZbJFtY94GRvMWp3qlMMN4dglK+8q/ +IrJurde4oBqipmwKu1dpq4aMS2ZX1pkbQX7CPxm//tfQiDxxdYJfu59J5vJ/kBgeWBt RLjSPx/pEHsw9aEPezm1NqC38AvwuI+zztJRp3GHeUvgOXn4JmF3Icnl+NM+Sislid65 SsaFHwN+N7vVNGOA2bF57ukxydOenC9Cf4bC61KlfFSIaqIv6akxLtIr6UYG2OY/a6lW wVHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=nCYNp39gdk8OY6IsNVveSNljSD3Em9HFvDgFPLDNcXY=; b=OWjqC/5rfjs4Ds6qbQW/o1+pWxcbiZFrbdN2gGImUe6HMQ9t5FEKOeaBHJFNh3L/S0 brIJqXeXvOrv9iYU7xeE704PTH/X+bKNS+OVWw+5BFXNYXPPCVfWHpeVs4/diW7slie3 HkjqvcdjpkpCVHajcEv3JguNQN5kpfz9sFEwwB2ovi8Vis/XsrvrpqgTUlGvEw0RQ3TA ILBhGmojV2V7RlC+9+Z6832hMpE+AsgwOdKheGnoXY+PxdIOXHSYRF0wPwq7Nl3Ryg5p i0vO7WwTOrNOy0eJ2wMNhSHQ82sEWqhfS8/bP/RkzQRGb0m4PyeH21ntt5VYHBxHFPee C4EA== X-Gm-Message-State: AOAM533g/nr3Rb9yVIOJaH3GxptqvNiMh74IpfsOCIkDoCkidkldEqoD FDryStNb2xQW4pceQGg8B5F6gKPm1BAjVg== X-Google-Smtp-Source: ABdhPJyD94Vf5Srv2+XUlJX6bH/p4Y6n5e9OUCA3An0KsVfP5M88bdogttCRIIGeiz86BzTrU+NWWw== X-Received: by 2002:adf:f34f:: with SMTP id e15mr14372487wrp.387.1600076355578; Mon, 14 Sep 2020 02:39:15 -0700 (PDT) Received: from [192.168.0.11] (79.108.125.160.dyn.user.ono.com. [79.108.125.160]) by smtp.googlemail.com with ESMTPSA id k84sm17770924wmf.6.2020.09.14.02.39.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2020 02:39:14 -0700 (PDT) To: Magnus Westerlund , "rlb@ipv.sx" , "magnus.westerlund=40ericsson.com@dmarc.ietf.org" , "sergio.garcia.murillo@cosmosoftware.io" Cc: "dispatch@ietf.org" , "iesg@ietf.org" , "sframe-chairs@ietf.org" , "sframe@ietf.org" References: <159949693494.2875.16993532753477402380@ietfa.amsl.com> <5c6c96621b29ebf4b1f84e53ae3a414c9d0ec3a5.camel@ericsson.com> <05085c6c-0c30-a407-8f41-b6c9be8100bc@gmail.com> <49b13e5efa0b2ac0a7b09842dbce8793dfcf6667.camel@ericsson.com> From: Sergio Garcia Murillo Message-ID: Date: Mon, 14 Sep 2020 11:39:15 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <49b13e5efa0b2ac0a7b09842dbce8793dfcf6667.camel@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Sframe] [dispatch] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2020 09:39:20 -0000 On 14/09/2020 9:29, Magnus Westerlund wrote: > Hi, > > Please see inline > > On Fri, 2020-09-11 at 17:32 +0200, Sergio Garcia Murillo wrote: >> On 11/09/2020 13:19, Magnus Westerlund wrote: >>> Hi, >>> >>>>> So do I assume correctly that the idea is that the application layer >>>>> using SFRAME if it haves multiple independent or sets of dependent >>>>> streams there will be no support for that aspect in SFRAME layer? >>>>> Instead it is up to the application to put such information to either >>>>> put it inside the encapsualted part of the SFRAME or map it to the >>>>> lower transport layer, like to RTP SSRCs and extension information. >>>> If i understood you correctly, SFrame is kind of agnostic to the media >>>> streams. Currently it has a single global frame counter for all the >>> transport, so >>>> the number of streams/dependency between them is not known/needed >>>> by SFrame. >>> Yes, and when using a multi-stream application with layered encoding being >>> protected by SFRAME and transported over RTP with repair functions the high >>> layer application will need to have a model for how it maps individual >>> SFRAMEs to RTP layer functions to enable them to do their work. You get a >>> very limited functionality if in an SFU system tries to send all over a >>> single RTP SSRC. So this becomes a discussion in the RTP Payload format >>> context when carrying SFRAMEs. >> >> I don't really understand your point, let's put an example vp9 svc. >> >> Chrome will encode each picture from the video stream and pass it to the >> vp9 svc encoder. The encoder will produce n-frames (one per spatial >> layer) for a given picture. >> >> Chrome will get each frame with its metadata (spatial/layer id + layer >> structure info + previous frame dependencies + future frame depencies) >> and pass it over to the insertable streams. >> >> The payload will go to javascript, in where SFRAME will encrypt it and >> returned as a binary blob. >> >> The browser will get the binary blob, packetize it in several rtp >> packets according to the new packetization format and add the metadata >> as a header extension. >> >> Is this process what you are describing or is there anything missing? >> > Then the client will send these RTP packets to an SFU that will need to make > decision on which of the packets to forward for which layers to a particular > receiver. To be able to do this there are first the aspect of that the meta data > needs to be included so that the SFU can make decision based on the packets it > recieves. In RTP context this likely are a more generic structure like the RTP > header extension for Frame marking (draft-ietf-avtext-framemarking). > > For packet it doesn't receive it lacks the meta data. Thus, for a more efficient > repair of packets that are missing and to repair only packets that the SFU > actually needs, then you actually have to map the layered structure into RTP > level structures so that the SFU can determine that the missing packet belongs > to a layer that it actually intends to forward. Putting everything in a single > SSRC requires the SFU to repair all losses independent of it needing the packet > or not. > > A even more extreme example is if the client has 3 video cameras and produce 3 > video encodings. In the SFRAME context it is possible to take the video frames > from all these threee encodings and put them in a single RTP stream (SSRC) with > SFRAMEs from that end-point. However, that would force your meta data to contain > also source identification rather than to using different SSRCs. Putting > multiple encoding on an single RTP stream would deprive the SFU of the > possibility to do rate control per encoding (RFC 5104 - TMMBR) as well as pause > streams it doesn't forward at all (RFC 7728 - Stream PAUSE) because all the > existing RTP mechanism that are included in WebRTC works on the RTP streams, not > sub-streams that doesn't have an identifier in the RTP layer. In addition to > having to repair any loss for the aggregated stream of the three encodings. No one has spoken of putting every on a single SSRC, the new rtp packetization would change the way the payload is packetized into the RTP packets, but not the rtp/ssrc/mid mapping of the media streams which would be the same as if not SFRAME is use. So this is a non-issue. > >>>>>> However, if the encrypted output is going to be transmitted over RTP >>>>>> using a new packetization format, we need to address how to negotiate >>>>>> that in the SDP. >>>>> Good >>>>> >>>>>> Note that this new packetization format will not only be alid for >>>>>> transporting encrypted frames (SFrame or not) but even any other >>>>>> audio/video frames. >>>>> I understand the potential exists. However, the recommendation for RTP >>>>> has been to try to consider Application Level Framing. In the case of >>>>> SFRAME that consideration moves up above SFRAME in the choice of how >>>>> data is split into SFRAMEs. However, having an RTP paylaod format for >>>>> SFRAME, then that should carry SFRAMEs. If you starts putting in other >>>>> binary objects into it, then you create a new demultiplexing point for >>>>> format between the RTP payload format and the SFRAME processing. That >>>> appears unmotivated. >>>> >>>> >>>> Note that SFRAME is not the only encryption possible with w3c insertable >>>> streams, it is up to the application to define its own crypto if they >>> want. So >>>> the payload must be able to transport non-SFRAME opaque blobs. >>> So I would consider this a misuse of the RTP payload format. The media type >>> will be for SFRAMEs. I understand that you might not be able to prevent this >>> in WebRTC. However, from an interoperability point of view you will be >>> stating that this is SFRAMEs. RTP will not be able to tell a difference. But >>> I don't see that this is will explicitly support carrying other things than >>> SFRAME. Because that means bringing in other consideration including the >>> security model for the E2E usage. >> >> Not sure if ignoring the reality on how the packetization format is >> going to be used within insertable streams is a good idea. > If you are passing other things than SFRAME you are also sending them without > end-to-end protection. Why is this happening, if the information was intended > for the SFU, then I think we should identify it as such, rather than having the > SFU have to hunt for it. If not, why are you sending it outside of the SFRAME > envelope? This is an application concern. I don't know why they would choose to do it, but the fact is that they can do it. > >> >>>>> Should the RTP payload format aspect of the charter be more explicit >>>>> in that it needs to disucss the general model of how to use SFRAME and >>>>> how an application can use the facilities of RTP to get good >>>>> performance from RTP mechanism like FEC and retransmission? >>>> I don't think so, RTX and FEC frames MUST not be modified/affected by >>>> SFRAME/the new packetization format, so they work out of the box. We can >>>> be explicit about that in the chapter as a requirement. >>>> >>> So I am not saying that RTX or FEC shall be modified. What I am saying is >>> that the SFRAME payload format should discuss the impact on the performance >>> of these functions depending on how you structure the SFRAMES across SSRCs. >>> The most simple example is the one where you put all layers for a video >>> encoding in a single SSRC. In such a stream you loose a single RTP packet >>> between the transmitting end-point and the SFU. Now the SFU is only >>> forwarding the base layer and not the enhancement layers. If base layer and >>> enhancement layer share RTP stream, the SFU can't determine if the missing >>> packet contains an base layer data or enhancement layer data. If the base >>> layer and enhancement layer would be on different SSRC, the fact that there >>> is a missing packet on the enhancement layer RTP stream means that the SFU >>> can ignore that as it anyway are not forwarding it. This same argument can >>> be applied between media sources. So how you map your application level >>> structures onto RTP do matter for the resulting performance of RTP. Putting >>> all on a single SSRC is not a path to good transport performance. >> >> But that is already the case for SVC codecs, so there is nothing new to >> specify in that regard. > So for SVC and other scalable codes there exists options for how to do this. And > where you can write and RTP packetizer for SVC that takes basicaly a mode and a > layer structure configuration as input, that is not possible for SFRAME as that > information is not visible in the RTP payload information. Instead it must come > with each SFRAME to packetize how to map it to the RTP layer. > > Thus, in my view the SFRAME RTP Payload format needs to discuss the core of > these issues to make it clear to the application both its options as well as > point to the impact of those options. This is already possible for any SVC codec re-using the Dependency Descriptor header extension: https://aomediacodec.github.io/av1-rtp-spec/#a1-introduction If you read my example above, this information is know before the frame goes to the Insertable Stream process, so it will be available for the rtp packetization without going via SFRAME. Best regards Sergio From nobody Mon Sep 14 07:12:44 2020 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 7A7593A083B; Mon, 14 Sep 2020 07:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.795 X-Spam-Level: X-Spam-Status: No, score=-3.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, 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 d96hiOm_4C8U; Mon, 14 Sep 2020 07:12:31 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0602.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::602]) (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 B57D33A07F2; Mon, 14 Sep 2020 07:12:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eMATiUjc0NjGbyS+GPNuAPjo8SHS2GefIOj9Jph5n8vzEoSTkfjg1DYYBDlWgy3e7rmVIWdt4mkos6hckSlmXUMHAeVj1P+mLCiWQI3a1HUqoOK593rYWcvDmUpPw8sO9vfXw6hNssa+NNiUG4gxV6FE/6us9hWNoFkLKNWJzP43h5W7Sj5dDRJCPzcKseZWkPuyvSA9icndXMn7R2QUeGNS5wcumPoaOIp6qlbXu+0cXo9s+WWgrjsZVzVVxo9FP5YbBV34eujxP4QvGGXb4cLMPRw/RYh9MDf/6NoORG/0FNKXTBcVb+AQGAPuAJ165g0dPiXBXOCUMMbvvYttzw== 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=kufU7MMEFlgrHY3k4+KpgbIAjhPcQIzMha/MP4Pi+fU=; b=GdGVXI17us3zyBzs5yICX0jj5yi+iGJ3PeRkcwsyWE0FEk39e/CclU1LuS7q2UQGv5oLzjydKjth9+UQo7mr7v/ROcnYMg+9uhZjPhaNaH9+s27+V3DRFgqwnuvJ7ELT8OFweBoT2sBzlsQQhnysa5tY2eatC/ASHHrcVXj1xFd8+3XBUZs78Eu56jxRppo4vnD+kJjpI8/9WeDxAzlxfq6STf40Ml3DGzM98pm24sOgYOmrFfwEYMO2wh0eO8w7t8SK/yYfx8cGwOTw/DH+QbFxwcuaaS5JdhPDuGYo5mA1YhFaSgFC3DsoQFOkhrOauCBNbRCDX+ajSYJmtQN4Mw== 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=kufU7MMEFlgrHY3k4+KpgbIAjhPcQIzMha/MP4Pi+fU=; b=gLT0rb0DqeBy55qhOd8J6fmPhiwR8WKeQsJmij0b+UCZV8rsY0rgoX7wcybTrz53B7aE+M6xm66QcL7IzyC3QPlfWFqMSAp/6Yhlk2uc0+/jLtnNQlSI3A6nYBFP4vZqqGhYyzAEat483+zVSw6H5RH8CH8j8Gzdq237AVFzWmU= Received: from VI1PR0702MB3775.eurprd07.prod.outlook.com (2603:10a6:803:10::30) by VI1PR07MB6544.eurprd07.prod.outlook.com (2603:10a6:800:182::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3370.7; Mon, 14 Sep 2020 14:12:27 +0000 Received: from VI1PR0702MB3775.eurprd07.prod.outlook.com ([fe80::3d12:319b:2c4b:5f23]) by VI1PR0702MB3775.eurprd07.prod.outlook.com ([fe80::3d12:319b:2c4b:5f23%2]) with mapi id 15.20.3391.009; Mon, 14 Sep 2020 14:12:27 +0000 From: Magnus Westerlund To: "magnus.westerlund=40ericsson.com@dmarc.ietf.org" , "rlb@ipv.sx" , "sergio.garcia.murillo@gmail.com" , "sergio.garcia.murillo@cosmosoftware.io" CC: "dispatch@ietf.org" , "iesg@ietf.org" , "sframe@ietf.org" Thread-Topic: [dispatch] [Sframe] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) Thread-Index: AQHWhTXfuLaYkFC4LEWqC8j5AGiLAKlh8DkAgAASwICAALgzgIAAV8mAgAAoYICAAA/A0IAAS+mAgAQwQoCAACQlgIAATFQA Date: Mon, 14 Sep 2020 14:12:27 +0000 Message-ID: References: <159949693494.2875.16993532753477402380@ietfa.amsl.com> <5c6c96621b29ebf4b1f84e53ae3a414c9d0ec3a5.camel@ericsson.com> <05085c6c-0c30-a407-8f41-b6c9be8100bc@gmail.com> <49b13e5efa0b2ac0a7b09842dbce8793dfcf6667.camel@ericsson.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [158.174.116.90] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9da0b1d8-67b7-43f7-46ee-08d858b8360b x-ms-traffictypediagnostic: VI1PR07MB6544: 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: FWiiR130Dti7xbdtXHmd9wSdtJt4liLo7PuUpgHt9z7ygOtL9/87nUaQlwpjsnKriNmaHx1PjeN9l3Ig/EsIdU1r5XvciFo+CgFLgcJz2PUrzZy+WRY61jWgusqi+qcqxkugh3YxJndWEullWEVnzXG+mT8dFN81Tf8eUEb13eb++UvifBOrSifp49txRMQ6umdYcVSsNLiAM24/ubQRM8oyihNUFGD41NlJX4yrX3rLefEKhRbJGJjtGj5JaPwq0p7PeFPKeiE/HiAPNUFO/PcvalvleeTiRFuCPg+RVWA5CMNKR13JM2wTWZFia5iV6KbxYRlIQEoSKJS2WQwByh3XKQ5NglVGouAgfilbLxgOT683LiQIte62GqzQV0kPtatkThqlcBWtDU1DrMlwsvUdSil/X9m0kFOVxNk7dpZZNkMsij/xrCsM+hLIRH+VUksBM3JFILzaKwxrxSHjCg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0702MB3775.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(366004)(136003)(396003)(376002)(346002)(91956017)(54906003)(71200400001)(6512007)(186003)(6486002)(2616005)(66556008)(66946007)(316002)(26005)(83380400001)(76116006)(6506007)(66476007)(66446008)(64756008)(44832011)(36756003)(966005)(508600001)(110136005)(86362001)(8676002)(4326008)(2906002)(5660300002)(8936002)(83080400001)(99106002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 0+4IdVSzdgqsQFJCSoJNnrgBOAUYanPiNX/CgVa+8sG8+XzSeQn4uMEP/kTpJhMrJxqN65/VmVqx91pm7atfQ8d6trlNsv0lZmdd1R0eSfn+z5VOOAyM6XhXalF0O0TgxQl6xq7bv8puGHh+tpcohoSPJ9XFhn3a1Jhh4HhORfH0RrBPyfwNu/xN2WkiNZK3/OgqTcWnBRs7YKLRisrrE8ht8hzMQnX1YBh+qq702LPlDc/zwVpZa6s+YJuuIcpFL6BhyaO0td9BaKwXWAXXWUaYsfh3Tp6KSjx/jlvAhjiw7YRTPX9ej7sc9/SuFdDE6Ar+5HbmlEZIPXkmKlwG33HICVbuQYqS6umDOJiGfcrid1x+DC1NdFec7YkLVMaDa1oJlvR1KCGtlDu5TPX/Irrw875Rmv8pleUpWsT9k1bGt6EGKiaXZsHafMI6r3Y84uqR99xMRR1OknwqNdAQAkJR4hBJQ06FbQqWGDWExqEc261dyvWJkxUO2f7jC4MShMma0s12SZPerheTySFPmmHnE8KlMidcIbqd0FuZOemu5fhsaTuwMwBYuiqIBaZG58ryoMhMSDgBwXGDYIhQa9hF1cnHn/84R9R2OJTENz5ThI0O0ROYF5pcKP14AN+B1p9iIwv6lNcKIczU3Y/QeA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <3269F37A9CCA0A4D9966312DE5C0B86E@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR0702MB3775.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9da0b1d8-67b7-43f7-46ee-08d858b8360b X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2020 14:12:27.5841 (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: RmhacTlof81YXkhWzRLFGqTMTxWc4sSKHSNcNsAjKYME5q09dAbleTrje6Zba/bXMLwaScR/TOLlL4fQSDwVKExT0Y1VszV2082zI6h7ACE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6544 Archived-At: Subject: Re: [Sframe] [dispatch] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2020 14:12:36 -0000 U2VyZ2lvLA0KDQpIYXZpbmcgMjAgeWVhcnMgb2YgZXhwZXJpZW5jZSB3aXRoIFJUUCBwYXlsb2Fk IGZvcm1hdCBkZXNpZ25zIHNvbWUgb2YgeW91cg0KZm9ybXVsYXRpb25zIG1hZGUgbWUgYSBiaXQg d29ycmllZC4gQWZ0ZXIgdGhpcyBkaXNjdXNzaW9uIEkgdGhpbmsgd2UgYXJlIG11Y2gNCmNsb3Nl ciBvbiBhIGNvbW1vbiB1bmRlcnN0YW5kaW5nIG9mIHRoZSBoaWdoIGxldmVsIGZ1bmN0aW9uYWxp dHkgbmVjZXNzYXJ5LiANCg0KSG93ZXZlciwgdGhlcmUgd2lsbCBiZSBxdWVzdGlvbnMgYWJvdXQg d2hlcmUgd2UgZG9jdW1lbnQgdGhhdCBpbnRlcmFjdGlvbiBhbmQNCndoYXQgZGVwZW5kZW5jaWVz IHRoYXQgZG8gZXhpc3Qgb24gb3RoZXIgc3BlY2lmaWNhaXRvbnMgZm9yIHNjYWxhYmxlIGNvZGVj cyB0aGF0DQphcmUgZ2VuZXJpYyBhbmQgaXMgZGVzaXJhYmxlIHRvIHJlcXVpcmUgZnJvbSBSVFAg bWlkZGxlYm94ZXMuIEluIGFkZGl0aW9uIGV2ZW4NCndpdGhvdXQgUlRQIHRoZXJlIHdpbGwgYmUg bmVlZCBmcm9tIHRoZSBhcHBsaWNhdGlvbiB0byBjb25zaWRlciBob3cgaXQgY2FuDQp1dGlsaXpl IG9uZSBTRlJBTUUga2V5IGFuZCBpdHMgSVZzIHRvIGNhcnJ5IG11bHRpcGxlIGFwcGxpY2F0aW9u IHN1Yi1zdHJlYW1zIGFuZA0KdGhlIG5lZWQgdG8gZXhwb3NlIHRoYXQgdG8gbG93ZXIgbGF5ZXIg dHJhbnNwb3J0IGZ1bmN0aW9uIHRvIGFjaGl2ZXZlDQpwZXJmb3JtYW5jZSBnb2Fscy4gDQoNClNv IEkgdGhpbmsgc29tZSBjbGFyaWZpY2F0aW9uIG9uIHRoZSBSVFAgcGF5bG9hZCBmb3JtYXQgd29y aywgYW5kIGl0IHRoYXQgaXMNCmdvaW5nIHRvIGhhcHBlbiBpbiB0aGUgU0ZSQU1FIFdHLiBJZiBo YXBwZW5pbmcgaW4gU0ZSQU1FIFdHIEkgd291bGQgbGlrZSB0byBoYXZlDQphIGpvaW50IFdHIExh c3QgY2FsbCB3aXRoIEFWVENPUkUgV0cuIA0KDQoNCk9uIE1vbiwgMjAyMC0wOS0xNCBhdCAxMToz OSArMDIwMCwgU2VyZ2lvIEdhcmNpYSBNdXJpbGxvIHdyb3RlOg0KPiANCj4gVGhpcyBpcyBhbHJl YWR5IHBvc3NpYmxlIGZvciBhbnkgU1ZDIGNvZGVjIHJlLXVzaW5nIHRoZSBEZXBlbmRlbmN5IA0K PiBEZXNjcmlwdG9yIGhlYWRlciBleHRlbnNpb246DQo+IA0KPiANCmh0dHBzOi8vcHJvdGVjdDIu ZmlyZWV5ZS5jb20vdjEvdXJsP2s9NmVmY2UzYWItMzA1YzIwMDItNmVmY2EzMzAtODY5NTllNDcy MjQzLTIwZmJkZjEzZDdlOTgyNTgmcT0xJmU9ZDQwODJiMWQtYzVhYy00OTQ2LWJlMTItNmE3MGE0 ODM4YWExJnU9aHR0cHMlM0ElMkYlMkZhb21lZGlhY29kZWMuZ2l0aHViLmlvJTJGYXYxLXJ0cC1z cGVjJTJGJTIzYTEtaW50cm9kdWN0aW9uDQo+IA0KDQpTbyBzaG91bGQgZGVmaW5pbmcgdGhlIGRl cGVuZGVuY3kgZGVzY3JpcHRvciBpbiBJRVRGIGJlIHBhcnQgb2YgdGhlIFNGUkFNRSBXRywNCm9y IGlzIHRoaXMgYSBub3JtYXRpdmUgZGVwZW5kZW5jeT8gQ3VycmVudGx5IHRoaXMgaXMgYSBpbmR1 c3RyeSBmb3J1bSBoZWFkZXINCmV4dGVuc2lvbiBub3QgYW4gSUVURiBwcm9kdWN0LiBBbmQgd2hh dCBzaG9ydCBjb21taW5ncyBvZiBGcmFtZSBNYXJraW5nIGlzIGl0DQphZGRyZXNzaW5nLiANCg0K IA0KQ2hlZXJzDQoNCk1hZ251cyBXZXN0ZXJsdW5kIA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCk5ldHdv cmtzLCBFcmljc3NvbiBSZXNlYXJjaA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRXJpY3Nzb24gQUIgICAgICAg ICAgICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5DQpUb3JzaGFtbnNnYXRhbiAyMyAgICAg ICAgICAgfA0KU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVuIHwgbWFpbHRvOiBtYWdudXMud2Vz dGVybHVuZEBlcmljc3Nvbi5jb20NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQo= From nobody Mon Sep 14 10:28:02 2020 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 8F0C93A0ACD; Mon, 14 Sep 2020 10:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 Arx0Y11u9DAG; Mon, 14 Sep 2020 10:27:50 -0700 (PDT) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 B99443A0D71; Mon, 14 Sep 2020 10:27:49 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id g4so514447wrs.5; Mon, 14 Sep 2020 10:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=dvlmBUJL3BL4rf9dUddHCNTln4PU/ybhi8Xlml5bBmQ=; b=OFdImHvgK1OnWC6J6L6cgDbkm9OpjdZ4MypLJ8MSmR0yO0/5w+8ITLUNrpsEQ1BY3M gkpJHcfSw/rjKqAh8MUroF0Ros+mMo0793sOGbaLnU7RFjQFBdXVz5Q63gEgD3CAphAJ GshCygliOk+oHKmPhon+n4imajrwMn48Yt4xKoAisE7IrqBworznx0kqSO5K8PHX1bJg +n3q0/Hl8sBzDtoBYjwVBh2jVnLluuEailBGKqxLsa96tU5/ldqx0bG0DHLYZZDKO0tP ELxXgrEmAUxVyXFPbTTyrAIpq1YKKZh7tXbpxGS9W4X7hCbP/f/GhifAj3bN6nKW7UDs 4qBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=dvlmBUJL3BL4rf9dUddHCNTln4PU/ybhi8Xlml5bBmQ=; b=SgKBUzeu+AkWoqqP6OcpSv65Bwg7ZxV6BKIqRkhbpzVBVAcrqqPAUXF45jxLoA/WjK L4+o+pVRBbz000ED3CfIBOetiKu3sW+MJUQWNqyYJW4pdIwvH+Tw8DdBO3ERU/LvDUUM z0/TIsofPH7p/wbAvWRvFoNwbgqpYfoRMyCmp6eVINFBBH/NAyiTUntOPjD4iS0Imles +cI5szzaRlZbHBK+Kk/S3/+q1E2g2oW+zVOkrTvMIwx9PgnTnBaIdFMzf3EqFJOncRnk YA+c1P0i4LmN89RcehU1yrn6vIJiFaJb8Ko1T3GWwsozMg6SLizYuRtYPG0guOw96Gwu kCDg== X-Gm-Message-State: AOAM533H8AQixDlBq0Ku+h/9foJFXC8yq5cvpWNbeBsPti8Tr94FETMk Zi7urzobmSz4WegaeK9jyl3pwz7BrwXbcw== X-Google-Smtp-Source: ABdhPJxoqDFs2P2gA/pEZnaY12pRm/9bJtXtaoBBgTiKrdZBNlBrIQQaDt2fO36ve3WOIzcNP4Czfg== X-Received: by 2002:a05:6000:12c3:: with SMTP id l3mr17973964wrx.164.1600104467904; Mon, 14 Sep 2020 10:27:47 -0700 (PDT) Received: from [192.168.0.11] (79.108.125.160.dyn.user.ono.com. [79.108.125.160]) by smtp.googlemail.com with ESMTPSA id q18sm21198428wre.78.2020.09.14.10.27.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2020 10:27:47 -0700 (PDT) To: Magnus Westerlund , "magnus.westerlund=40ericsson.com@dmarc.ietf.org" , "rlb@ipv.sx" , "sergio.garcia.murillo@cosmosoftware.io" Cc: "dispatch@ietf.org" , "iesg@ietf.org" , "sframe@ietf.org" References: <159949693494.2875.16993532753477402380@ietfa.amsl.com> <5c6c96621b29ebf4b1f84e53ae3a414c9d0ec3a5.camel@ericsson.com> <05085c6c-0c30-a407-8f41-b6c9be8100bc@gmail.com> <49b13e5efa0b2ac0a7b09842dbce8793dfcf6667.camel@ericsson.com> From: Sergio Garcia Murillo Message-ID: Date: Mon, 14 Sep 2020 19:27:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A6220C6C449DF6DA458D35E4" Content-Language: en-US Archived-At: Subject: Re: [Sframe] [dispatch] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2020 17:27:53 -0000 This is a multi-part message in MIME format. --------------A6220C6C449DF6DA458D35E4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 14/09/2020 16:12, Magnus Westerlund wrote: > Sergio, > > Having 20 years of experience with RTP payload format designs some of your > formulations made me a bit worried. After this discussion I think we are much > closer on a common understanding of the high level functionality necessary. > > However, there will be questions about where we document that interaction and > what dependencies that do exist on other specificaitons for scalable codecs that > are generic and is desirable to require from RTP middleboxes. In addition even > without RTP there will be need from the application to consider how it can > utilize one SFRAME key and its IVs to carry multiple application sub-streams and > the need to expose that to lower layer transport function to achiveve > performance goals. What I fail to understand is the nature of your concerns and how should we address them on the charter: * Is it something that we plan to do that is not covered in the charter? * Is it something that we don't plan to do but the charter is wide enough to allow it? * Is it something that we plan to do and it is covered in the charter but you don't agree to it? * Is it something that we don't plan to do and is neither covered by the charter and we should add it? > So I think some clarification on the RTP payload format work, and it that is > going to happen in the SFRAME WG. If happening in SFRAME WG I would like to have > a joint WG Last call with AVTCORE WG. I raised that question already a couple of times. I am not sure what is the role of the SFRAME WG regarding specifying a new RTP codec-agnostic payload. IMHO this WG should collect the requirements, match them to current specifications, and if anything is missing, liaise with the appropriate groups in order to produce the specs based on our requirements. Best regards Sergio --------------A6220C6C449DF6DA458D35E4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 14/09/2020 16:12, Magnus Westerlund wrote:
Sergio,

Having 20 years of experience with RTP payload format designs some of your
formulations made me a bit worried. After this discussion I think we are much
closer on a common understanding of the high level functionality necessary. 

However, there will be questions about where we document that interaction and
what dependencies that do exist on other specificaitons for scalable codecs that
are generic and is desirable to require from RTP middleboxes. In addition even
without RTP there will be need from the application to consider how it can
utilize one SFRAME key and its IVs to carry multiple application sub-streams and
the need to expose that to lower layer transport function to achiveve
performance goals.


What I fail to understand is the nature of your concerns and how should we address them on the charter:

  • Is it something that we plan to do that is not covered in the charter?
  • Is it something that we don't plan to do but the charter is wide enough to allow it?
  • Is it something that we plan to do and it is covered in the charter but you don't agree to it?
  • Is it something that we don't plan to do and is neither covered by the charter and we should add it?


So I think some clarification on the RTP payload format work, and it that is
going to happen in the SFRAME WG. If happening in SFRAME WG I would like to have
a joint WG Last call with AVTCORE WG.


I raised that question already a couple of times. I am not sure what is the role of the SFRAME WG regarding specifying a new RTP codec-agnostic payload.

IMHO this WG should collect the requirements, match them to current specifications, and if anything is missing, liaise with the appropriate groups in order to produce the specs based on our requirements.

Best regards

Sergio

--------------A6220C6C449DF6DA458D35E4-- From nobody Mon Sep 14 11:46:12 2020 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 581A03A0E70; Mon, 14 Sep 2020 11:46:05 -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 UFio3QwqZoi7; Mon, 14 Sep 2020 11:46:02 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 797213A0E72; Mon, 14 Sep 2020 11:46:01 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id z17so339076lfi.12; Mon, 14 Sep 2020 11:46:01 -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=QtsqthO/n+DlH07Pnq4pR+L8wnPw0FWM2oDBYWuUpQg=; b=rn27AxAQ4x3AbYOOcHLSt+1+6QRHIfXhOuZjDvWpSbLQSQGDqeMBANyiizvJUBwo8a r+CLy9k5Y2Lq9OuO9txW5dtFplpuYLaCNRNY5vbMdYf4KlUlx2pupbPrwBKBZrffmKEq kAiMQnJ3aFVWGTrGPfHktoVcSoPnC0p2f31hJ+gRawqKueQ06PYS4u8hENZYjotgGznx nJ9SvX74qEk1co4eYzHtKhlCYKHpSVe6nVBxYurNQ+tvRi3GZbsTALm62GcPfDUKceqC 4lu9QcOt+a0GHNCAqlztSWulgjF+f2303dk4PQU8plT8gBuXZfeSx/5TMIzPO2M9gcin OQdg== 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=QtsqthO/n+DlH07Pnq4pR+L8wnPw0FWM2oDBYWuUpQg=; b=Ak/fwOaW3APtwFMTQok/+sgnjMSrGNvgp/N64+jAwpqZv6L+PjT14riPI5mLN2FcJZ g4FmmiTyZwT3wviS5/PCR4Zn5FJjZAawFXcwwQvb6IVtlcvZ+qRpWAX3ETFSFsdDBYWj qwUSvNUXTIAoWputuBmAcl6YYyS8DJTM5Oq2J8IE1fiEaWFJFhWLg8xR+46vU7YvqR1e b/ihOh28Op8Ry2wsEvLa2ZUbReg9/Znc60i7w1KbJ29J2Gjzq4Mf/b3lJCmPUHuIZ4AP NTZlszE8hVY35IIY28LmTD5tv2na1OGlqS6a0L+ESuiWHsP3ZTe+eoejH+jkxa8mvTKG qdow== X-Gm-Message-State: AOAM530gPC10ZwpMofMNA19X84EJcmdjJ64cw3RO1GuBoIwle937TYIu cBBVFdftrk+jFFcVGzZABGgzIOXmC3OX+DrTPbo= X-Google-Smtp-Source: ABdhPJx8/weAx+0LH5ja8SsDsOirbLdbHb8iETKRKf/eq3Pa4r+qdDd5jS9qx0DaG5BV0css1GCC65BbNUpaZDAoWWc= X-Received: by 2002:a19:ad08:: with SMTP id t8mr4812763lfc.41.1600109159207; Mon, 14 Sep 2020 11:45:59 -0700 (PDT) MIME-Version: 1.0 References: <159949693494.2875.16993532753477402380@ietfa.amsl.com> <5c6c96621b29ebf4b1f84e53ae3a414c9d0ec3a5.camel@ericsson.com> <05085c6c-0c30-a407-8f41-b6c9be8100bc@gmail.com> <49b13e5efa0b2ac0a7b09842dbce8793dfcf6667.camel@ericsson.com> In-Reply-To: From: Bernard Aboba Date: Mon, 14 Sep 2020 11:45:49 -0700 Message-ID: To: Sergio Garcia Murillo Cc: Magnus Westerlund , "rlb@ipv.sx" , "magnus.westerlund=40ericsson.com@dmarc.ietf.org" , "sergio.garcia.murillo@cosmosoftware.io" , "sframe-chairs@ietf.org" , "dispatch@ietf.org" , "iesg@ietf.org" , "sframe@ietf.org" Content-Type: multipart/alternative; boundary="000000000000095d4305af4a72c6" Archived-At: Subject: Re: [Sframe] [dispatch] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2020 18:46:05 -0000 --000000000000095d4305af4a72c6 Content-Type: text/plain; charset="UTF-8" Sergio said: "No one has spoken of putting everything on a single SSRC, the new RTP packetization would change the way the payload is packetized into the RTP packets, but not the rtp/ssrc/mid mapping of the media streams which would be the same as if SFRAME is not in use. So this is a non-issue." [BA] Right. SFRAME doesn't change the SSRC allocation scheme, nor does it prevent the SFU from modifying the SSRC. If the application was sending simulcast with multiple SSRCs/RIDs, SFRAME won't affect that. Similarly with SVC, if the application was sending all layers on a single SSRC, SFRAME won't change that either. "If you read my example above, this information is known before the frame goes to the Insertable Stream process, so it will be available for the RTP packetization without going via SFRAME." [BA] As you note, the metadata contains information about each frame, and the Insertable Streams implementation assumes that the application modifications don't invalidate the metadata, which currently contains info such as frame type, frameId, dependencies, width, height, LID, TID, SSRC and CSRCs. Most of the RTP header extension fields are the same for each packet within a frame; only a few will change between packets within a frame, such as the Start and End bits. The exercise is to make sure that the metadata is sufficient to enable the generic RTP packetizer to fill in all the RTP header and RTP header extension fields. For the RTP header extension fields, this includes info such as Discardable, Switch, Required, Base Layer Sync, etc. Today it isn't clear to me that this info is completely determinable from the Insertable Streams metadata. Given that we don't have a lot of deployment of frame forwarding RTP header extensions yet, it's probably best to avoid tying SFRAME to any particular design. For example, you wouldn't want a design that could only function with the framemarking RTP header extension or the Generic Frame Descriptor or the Dependency Descriptor, so that a new specification is needed when the N+1 frame forwarding technology comes along. On Mon, Sep 14, 2020 at 2:39 AM Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > On 14/09/2020 9:29, Magnus Westerlund wrote: > > Hi, > > > > Please see inline > > > > On Fri, 2020-09-11 at 17:32 +0200, Sergio Garcia Murillo wrote: > >> On 11/09/2020 13:19, Magnus Westerlund wrote: > >>> Hi, > >>> > >>>>> So do I assume correctly that the idea is that the application layer > >>>>> using SFRAME if it haves multiple independent or sets of dependent > >>>>> streams there will be no support for that aspect in SFRAME layer? > >>>>> Instead it is up to the application to put such information to either > >>>>> put it inside the encapsualted part of the SFRAME or map it to the > >>>>> lower transport layer, like to RTP SSRCs and extension information. > >>>> If i understood you correctly, SFrame is kind of agnostic to the media > >>>> streams. Currently it has a single global frame counter for all the > >>> transport, so > >>>> the number of streams/dependency between them is not known/needed > >>>> by SFrame. > >>> Yes, and when using a multi-stream application with layered encoding > being > >>> protected by SFRAME and transported over RTP with repair functions the > high > >>> layer application will need to have a model for how it maps individual > >>> SFRAMEs to RTP layer functions to enable them to do their work. You > get a > >>> very limited functionality if in an SFU system tries to send all over a > >>> single RTP SSRC. So this becomes a discussion in the RTP Payload format > >>> context when carrying SFRAMEs. > >> > >> I don't really understand your point, let's put an example vp9 svc. > >> > >> Chrome will encode each picture from the video stream and pass it to the > >> vp9 svc encoder. The encoder will produce n-frames (one per spatial > >> layer) for a given picture. > >> > >> Chrome will get each frame with its metadata (spatial/layer id + layer > >> structure info + previous frame dependencies + future frame depencies) > >> and pass it over to the insertable streams. > >> > >> The payload will go to javascript, in where SFRAME will encrypt it and > >> returned as a binary blob. > >> > >> The browser will get the binary blob, packetize it in several rtp > >> packets according to the new packetization format and add the metadata > >> as a header extension. > >> > >> Is this process what you are describing or is there anything missing? > >> > > Then the client will send these RTP packets to an SFU that will need to > make > > decision on which of the packets to forward for which layers to a > particular > > receiver. To be able to do this there are first the aspect of that the > meta data > > needs to be included so that the SFU can make decision based on the > packets it > > recieves. In RTP context this likely are a more generic structure like > the RTP > > header extension for Frame marking (draft-ietf-avtext-framemarking). > > > > For packet it doesn't receive it lacks the meta data. Thus, for a more > efficient > > repair of packets that are missing and to repair only packets that the > SFU > > actually needs, then you actually have to map the layered structure into > RTP > > level structures so that the SFU can determine that the missing packet > belongs > > to a layer that it actually intends to forward. Putting everything in a > single > > SSRC requires the SFU to repair all losses independent of it needing the > packet > > or not. > > > > A even more extreme example is if the client has 3 video cameras and > produce 3 > > video encodings. In the SFRAME context it is possible to take the video > frames > > from all these threee encodings and put them in a single RTP stream > (SSRC) with > > SFRAMEs from that end-point. However, that would force your meta data to > contain > > also source identification rather than to using different SSRCs. Putting > > multiple encoding on an single RTP stream would deprive the SFU of the > > possibility to do rate control per encoding (RFC 5104 - TMMBR) as well > as pause > > streams it doesn't forward at all (RFC 7728 - Stream PAUSE) because all > the > > existing RTP mechanism that are included in WebRTC works on the RTP > streams, not > > sub-streams that doesn't have an identifier in the RTP layer. In > addition to > > having to repair any loss for the aggregated stream of the three > encodings. > > No one has spoken of putting every on a single SSRC, the new rtp > packetization would change the way the payload is packetized into the > RTP packets, but not the rtp/ssrc/mid mapping of the media streams which > would be the same as if not SFRAME is use. So this is a non-issue. > > > > > >>>>>> However, if the encrypted output is going to be transmitted over RTP > >>>>>> using a new packetization format, we need to address how to > negotiate > >>>>>> that in the SDP. > >>>>> Good > >>>>> > >>>>>> Note that this new packetization format will not only be alid for > >>>>>> transporting encrypted frames (SFrame or not) but even any other > >>>>>> audio/video frames. > >>>>> I understand the potential exists. However, the recommendation for > RTP > >>>>> has been to try to consider Application Level Framing. In the case of > >>>>> SFRAME that consideration moves up above SFRAME in the choice of how > >>>>> data is split into SFRAMEs. However, having an RTP paylaod format for > >>>>> SFRAME, then that should carry SFRAMEs. If you starts putting in > other > >>>>> binary objects into it, then you create a new demultiplexing point > for > >>>>> format between the RTP payload format and the SFRAME processing. That > >>>> appears unmotivated. > >>>> > >>>> > >>>> Note that SFRAME is not the only encryption possible with w3c > insertable > >>>> streams, it is up to the application to define its own crypto if they > >>> want. So > >>>> the payload must be able to transport non-SFRAME opaque blobs. > >>> So I would consider this a misuse of the RTP payload format. The media > type > >>> will be for SFRAMEs. I understand that you might not be able to > prevent this > >>> in WebRTC. However, from an interoperability point of view you will be > >>> stating that this is SFRAMEs. RTP will not be able to tell a > difference. But > >>> I don't see that this is will explicitly support carrying other things > than > >>> SFRAME. Because that means bringing in other consideration including > the > >>> security model for the E2E usage. > >> > >> Not sure if ignoring the reality on how the packetization format is > >> going to be used within insertable streams is a good idea. > > If you are passing other things than SFRAME you are also sending them > without > > end-to-end protection. Why is this happening, if the information was > intended > > for the SFU, then I think we should identify it as such, rather than > having the > > SFU have to hunt for it. If not, why are you sending it outside of the > SFRAME > > envelope? > > This is an application concern. I don't know why they would choose to do > it, but the fact is that they can do it. > > > > > >> > >>>>> Should the RTP payload format aspect of the charter be more explicit > >>>>> in that it needs to disucss the general model of how to use SFRAME > and > >>>>> how an application can use the facilities of RTP to get good > >>>>> performance from RTP mechanism like FEC and retransmission? > >>>> I don't think so, RTX and FEC frames MUST not be modified/affected by > >>>> SFRAME/the new packetization format, so they work out of the box. We > can > >>>> be explicit about that in the chapter as a requirement. > >>>> > >>> So I am not saying that RTX or FEC shall be modified. What I am saying > is > >>> that the SFRAME payload format should discuss the impact on the > performance > >>> of these functions depending on how you structure the SFRAMES across > SSRCs. > >>> The most simple example is the one where you put all layers for a video > >>> encoding in a single SSRC. In such a stream you loose a single RTP > packet > >>> between the transmitting end-point and the SFU. Now the SFU is only > >>> forwarding the base layer and not the enhancement layers. If base > layer and > >>> enhancement layer share RTP stream, the SFU can't determine if the > missing > >>> packet contains an base layer data or enhancement layer data. If the > base > >>> layer and enhancement layer would be on different SSRC, the fact that > there > >>> is a missing packet on the enhancement layer RTP stream means that the > SFU > >>> can ignore that as it anyway are not forwarding it. This same argument > can > >>> be applied between media sources. So how you map your application level > >>> structures onto RTP do matter for the resulting performance of RTP. > Putting > >>> all on a single SSRC is not a path to good transport performance. > >> > >> But that is already the case for SVC codecs, so there is nothing new to > >> specify in that regard. > > So for SVC and other scalable codes there exists options for how to do > this. And > > where you can write and RTP packetizer for SVC that takes basicaly a > mode and a > > layer structure configuration as input, that is not possible for SFRAME > as that > > information is not visible in the RTP payload information. Instead it > must come > > with each SFRAME to packetize how to map it to the RTP layer. > > > > Thus, in my view the SFRAME RTP Payload format needs to discuss the core > of > > these issues to make it clear to the application both its options as > well as > > point to the impact of those options. > > > This is already possible for any SVC codec re-using the Dependency > Descriptor header extension: > > https://aomediacodec.github.io/av1-rtp-spec/#a1-introduction > > If you read my example above, this information is know before the frame > goes to the Insertable Stream process, so it will be available for the > rtp packetization without going via SFRAME. > > > Best regards > > Sergio > > -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --000000000000095d4305af4a72c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sergio said:=C2=A0
<= br>
"No one has spoken of putting everything on a single SSR= C, the new RTP
packetization would change the way the payload is packe= tized into the
RTP packets, but not the rtp/ssrc/mid mapping of the medi= a streams which
would be the same as if SFRAME is not in use. So th= is is a non-issue."

[BA] Right.=C2=A0 SFRAME = doesn't change the SSRC allocation scheme, nor does it prevent the SFU = from modifying the SSRC.=C2=A0
If the application was sending sim= ulcast with multiple SSRCs/RIDs, SFRAME won't affect that.=C2=A0 Simila= rly with SVC, if the application was sending all layers on a single SSRC, S= FRAME won't change that either.=C2=A0

"If= you read my example above, this information is known before the frame goes= to the Insertable Stream process, so it will be available for the RTP pack= etization without going via SFRAME."

[BA] As = you note, the metadata contains information about each frame, and the Inser= table Streams implementation assumes that the application modifications don= 't invalidate the=C2=A0metadata, which currently contains info such as = frame type, frameId, dependencies, width, height, LID, TID, SSRC and CSRCs.= =C2=A0

Most of the RTP header extension fields are= the same for each packet within a frame; only a few will change between pa= ckets within a frame, such as the Start and End bits.=C2=A0

<= /div>
The exercise is to make sure that the metadata is sufficient to e= nable the generic RTP packetizer to fill in all the RTP header and RTP head= er extension fields.=C2=A0 For the RTP header extension fields, this includ= es info such as Discardable, Switch, Required, Base Layer Sync, etc.=C2=A0 = Today it isn't clear to me that this info is completely determinable fr= om the Insertable Streams metadata.=C2=A0

Given th= at we don't have a lot of deployment of frame forwarding RTP header ext= ensions yet, it's probably best to avoid tying SFRAME=C2=A0 to any part= icular design.=C2=A0 For example, you wouldn't want a design that could= only function with the framemarking=C2=A0RTP header extension or the Gener= ic Frame Descriptor or the Dependency Descriptor, so that a new specificati= on is needed when the N+1 frame forwarding technology comes along.=C2=A0







On Mon, Sep 14, 2020 at 2:39 AM Sergio Garcia= Murillo <sergio.garc= ia.murillo@gmail.com> wrote:
On 14/09/2020 9:29, Magnus Westerlund wrote:
> Hi,
>
> Please see inline
>
> On Fri, 2020-09-11 at 17:32 +0200, Sergio Garcia Murillo wrote:
>> On 11/09/2020 13:19, Magnus Westerlund wrote:
>>> Hi,
>>>
>>>>> So do I assume correctly that the idea is that the app= lication layer
>>>>> using SFRAME if it haves multiple independent or sets = of dependent
>>>>> streams there will be no support for that aspect in SF= RAME layer?
>>>>> Instead it is up to the application to put such inform= ation to either
>>>>> put it inside the encapsualted part of the SFRAME or m= ap it to the
>>>>> lower transport layer, like to RTP SSRCs and extension= information.
>>>> If i understood you correctly, SFrame is kind of agnostic = to the media
>>>> streams. Currently it has a single global frame counter fo= r all the
>>> transport, so
>>>> the number of streams/dependency between them is not known= /needed
>>>> by SFrame.
>>> Yes, and when using a multi-stream application with layered en= coding being
>>> protected by SFRAME and transported over RTP with repair funct= ions the high
>>> layer application will need to have a model for how it maps in= dividual
>>> SFRAMEs to RTP layer functions to enable them to do their work= . You get a
>>> very limited functionality if in an SFU system tries to send a= ll over a
>>> single RTP SSRC. So this becomes a discussion in the RTP Paylo= ad format
>>> context when carrying SFRAMEs.
>>
>> I don't really understand your point, let's put an example= vp9 svc.
>>
>> Chrome will encode each picture from the video stream and pass it = to the
>> vp9 svc encoder. The encoder will produce n-frames (one per spatia= l
>> layer) for a given picture.
>>
>> Chrome will get each frame with its metadata (spatial/layer id + l= ayer
>> structure info + previous frame dependencies + future frame depenc= ies)
>> and pass it over to the insertable streams.
>>
>> The payload will go to javascript, in where SFRAME will encrypt it= and
>> returned as a binary blob.
>>
>> The browser will get the binary blob, packetize it in several rtp<= br> >> packets according to the new packetization format and add the meta= data
>> as a header extension.
>>
>> Is this process what you are describing or is there anything missi= ng?
>>
> Then the client will send these RTP packets to an SFU that will need t= o make
> decision on which of the packets to forward for which layers to a part= icular
> receiver. To be able to do this there are first the aspect of that the= meta data
> needs to be included so that the SFU can make decision based on the pa= ckets it
> recieves. In RTP context this likely are a more generic structure like= the RTP
> header extension for Frame marking (draft-ietf-avtext-framemarking). >
> For packet it doesn't receive it lacks the meta data. Thus, for a = more efficient
> repair of packets that are missing and to repair only packets that the= SFU
> actually needs, then you actually have to map the layered structure in= to RTP
> level structures so that the SFU can determine that the missing packet= belongs
> to a layer that it actually intends to forward. Putting everything in = a single
> SSRC requires the SFU to repair all losses independent of it needing t= he packet
> or not.
>
> A even more extreme example is if the client has 3 video cameras and p= roduce 3
> video encodings. In the SFRAME context it is possible to take the vide= o frames
> from all these threee encodings and put them in a single RTP stream (S= SRC) with
> SFRAMEs from that end-point. However, that would force your meta data = to contain
> also source identification rather than to using different SSRCs. Putti= ng
> multiple encoding on an single RTP stream would deprive the SFU of the=
> possibility to do rate control per encoding (RFC 5104 - TMMBR) as well= as pause
> streams it doesn't forward at all (RFC 7728 - Stream PAUSE) becaus= e all the
> existing RTP mechanism that are included in WebRTC works on the RTP st= reams, not
> sub-streams that doesn't have an identifier in the RTP layer. In a= ddition to
> having to repair any loss for the aggregated stream of the three encod= ings.

No one has spoken of putting every on a single SSRC, the new rtp
packetization would change the way the payload is packetized into the
RTP packets, but not the rtp/ssrc/mid mapping of the media streams which would be the same as if not SFRAME is use. So this is a non-issue.


>
>>>>>> However, if the encrypted output is going to be tr= ansmitted over RTP
>>>>>> using a new packetization format, we need to addre= ss how to negotiate
>>>>>> that in the SDP.
>>>>> Good
>>>>>
>>>>>> Note that this new packetization format will not o= nly be alid for
>>>>>> transporting encrypted frames (SFrame or not) but = even any other
>>>>>> audio/video frames.
>>>>> I understand the potential exists. However, the recomm= endation for RTP
>>>>> has been to try to consider Application Level Framing.= In the case of
>>>>> SFRAME that consideration moves up above SFRAME in the= choice of how
>>>>> data is split into SFRAMEs. However, having an RTP pay= laod format for
>>>>> SFRAME, then that should carry SFRAMEs. If you starts = putting in other
>>>>> binary objects into it, then you create a new demultip= lexing point for
>>>>> format between the RTP payload format and the SFRAME p= rocessing. That
>>>> appears unmotivated.
>>>>
>>>>
>>>> Note that SFRAME is not the only encryption possible with = w3c insertable
>>>> streams, it is up to the application to define its own cry= pto if they
>>> want. So
>>>> the payload must be able to transport non-SFRAME opaque bl= obs.
>>> So I would consider this a misuse of the RTP payload format. T= he media type
>>> will be for SFRAMEs. I understand that you might not be able t= o prevent this
>>> in WebRTC. However, from an interoperability point of view you= will be
>>> stating that this is SFRAMEs. RTP will not be able to tell a d= ifference. But
>>> I don't see that this is will explicitly support carrying = other things than
>>> SFRAME. Because that means bringing in other consideration inc= luding the
>>> security model for the E2E usage.
>>
>> Not sure if ignoring the reality on how the packetization format i= s
>> going to be used within insertable streams is a good idea.
> If you are passing other things than SFRAME you are also sending them = without
> end-to-end protection. Why is this happening, if the information was i= ntended
> for the SFU, then I think we should identify it as such, rather than h= aving the
> SFU have to hunt for it. If not, why are you sending it outside of the= SFRAME
> envelope?

This is an application concern. I don't know why they would choose to d= o
it, but the fact is that they can do it.


>
>>
>>>>> Should the RTP payload format aspect of the charter be= more explicit
>>>>> in that it needs to disucss the general model of how t= o use SFRAME and
>>>>> how an application can use the facilities of RTP to ge= t good
>>>>> performance from RTP mechanism like FEC and retransmis= sion?
>>>> I don't think so, RTX and FEC frames MUST not be modif= ied/affected by
>>>> SFRAME/the new packetization format, so they work out of t= he box. We can
>>>> be explicit about that in the chapter as a requirement. >>>>
>>> So I am not saying that RTX or FEC shall be modified. What I a= m saying is
>>> that the SFRAME payload format should discuss the impact on th= e performance
>>> of these functions depending on how you structure the SFRAMES = across SSRCs.
>>> The most simple example is the one where you put all layers fo= r a video
>>> encoding in a single SSRC. In such a stream you loose a single= RTP packet
>>> between the transmitting end-point and the SFU. Now the SFU is= only
>>> forwarding the base layer and not the enhancement layers. If b= ase layer and
>>> enhancement layer share RTP stream, the SFU can't determin= e if the missing
>>> packet contains an base layer data or enhancement layer data. = If the base
>>> layer and enhancement layer would be on different SSRC, the fa= ct that there
>>> is a missing packet on the enhancement layer RTP stream means = that the SFU
>>> can ignore that as it anyway are not forwarding it. This same = argument can
>>> be applied between media sources. So how you map your applicat= ion level
>>> structures onto RTP do matter for the resulting performance of= RTP. Putting
>>> all on a single SSRC is not a path to good transport performan= ce.
>>
>> But that is already the case for SVC codecs, so there is nothing n= ew to
>> specify in that regard.
> So for SVC and other scalable codes there exists options for how to do= this. And
> where you can write and RTP packetizer for SVC that takes basicaly a m= ode and a
> layer structure configuration as input, that is not possible for SFRAM= E as that
> information is not visible in the RTP payload information. Instead it = must come
> with each SFRAME to packetize how to map it to the RTP layer.
>
> Thus, in my view the SFRAME RTP Payload format needs to discuss the co= re of
> these issues to make it clear to the application both its options as w= ell as
> point to the impact of those options.


This is already possible for any SVC codec re-using the Dependency
Descriptor header extension:

https://aomediacodec.github.io/av1-rtp-s= pec/#a1-introduction

If you read my example above, this information is know before the frame goes to the Insertable Stream process, so it will be available for the
rtp packetization without going via SFRAME.


Best regards

Sergio

--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--000000000000095d4305af4a72c6-- From nobody Mon Sep 14 12:43:21 2020 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 62EBD3A0B4F; Mon, 14 Sep 2020 12:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 PFwXxn1qq2Ka; Mon, 14 Sep 2020 12:43:13 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 183313A0B4B; Mon, 14 Sep 2020 12:43:13 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id a17so876982wrn.6; Mon, 14 Sep 2020 12:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=1Ta5KSw2xCBbgXCYSLA9bnWXLtlnXjE72BokVAxo2BU=; b=WLFxE8BggTTDa+95L/YQ3b8mF9UcD6ZHckUjMvZGxT7k/lY7KCERB7M/tI9lw+R74k xRxS1njDepmOX4a2ivqkRu9N+kHb3w0HLJCIjHfm4iy6aofjIjAby7ys9FqEl7F7nZYq S6lROLkCKRpjq9U6zEv0ZbJwTv5eqsocOf3rKPb/MulywHr7h7GpO5wxsWjfR9lMupJC agnjh01SaD/h9BQ7GXgdINfc5WAYgxAhbuzj4w/PrDHU0ZNVI4+Q4OX16jcmSrr6Brf2 D17e5T0PjdKhacHlQ/d9iSBVmzTE6baTY4tmbjZmjd+R3OrBoT09i6CSteVn+ur5wB0N S28w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=1Ta5KSw2xCBbgXCYSLA9bnWXLtlnXjE72BokVAxo2BU=; b=ns1AZ5/pSEG130TjNKidS5u7+8qEeKxgac0fDUmcI2zjzq/2Dh4p1iVRhIpgkI9Hce qVCJCXz+O/G0aWR3y7nOSrgTsNaDBm3f3x7hCgZArcmMPRc3pCWMwoIHUoPm0BOffKoS oBc/8Slh0pBrd6A+YYNjS3kp1AZ2JWOIoBLpiPeCpRH3PqVJbd07sG2xUwPzd/Ad8xGD 8a21mvcm/ZRe1hK21D9bmTG8NknKxQkXcFVZwcaQhp6GUc+Jc/onauumXK+ZLMv/vfO/ ZxVJjWkqA6Fc8iT3epD60KXdhC3S6rDueLuJpJBQYGUWkd4EJDebYDtHiHgWVJaikk/5 mJ+w== X-Gm-Message-State: AOAM532dgBnXIQEPJcKPu0JkgTffftZKlz2ovm1YnLAAXFXV6RP56CWu Hf+pB2KkMsBl8bc2214x5Xh6jZwK0LkvEA== X-Google-Smtp-Source: ABdhPJzcc16qTgyAaVTaLJ57RpoplffpEMzGrLC1WkWip7tWomiyCeETT+PZiCLDHkB9SAtplyYXcw== X-Received: by 2002:a05:6000:10c1:: with SMTP id b1mr13516507wrx.212.1600112591278; Mon, 14 Sep 2020 12:43:11 -0700 (PDT) Received: from [192.168.0.11] (79.108.125.160.dyn.user.ono.com. [79.108.125.160]) by smtp.googlemail.com with ESMTPSA id 59sm22398807wro.82.2020.09.14.12.43.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2020 12:43:10 -0700 (PDT) To: Bernard Aboba Cc: Magnus Westerlund , "rlb@ipv.sx" , "magnus.westerlund=40ericsson.com@dmarc.ietf.org" , "sergio.garcia.murillo@cosmosoftware.io" , "sframe-chairs@ietf.org" , "dispatch@ietf.org" , "iesg@ietf.org" , "sframe@ietf.org" References: <159949693494.2875.16993532753477402380@ietfa.amsl.com> <5c6c96621b29ebf4b1f84e53ae3a414c9d0ec3a5.camel@ericsson.com> <05085c6c-0c30-a407-8f41-b6c9be8100bc@gmail.com> <49b13e5efa0b2ac0a7b09842dbce8793dfcf6667.camel@ericsson.com> From: Sergio Garcia Murillo Message-ID: <10062d18-4e6b-fd76-eabd-9a746a7812fd@gmail.com> Date: Mon, 14 Sep 2020 21:43:09 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Sframe] [dispatch] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2020 19:43:15 -0000 On 14/09/2020 20:45, Bernard Aboba wrote: > > Given that we don't have a lot of deployment of frame forwarding RTP > header extensions yet, it's probably best to avoid tying SFRAME  to > any particular design.  For example, you wouldn't want a design that > could only function with the framemarking RTP header extension or the > Generic Frame Descriptor or the Dependency Descriptor, so that a new > specification is needed when the N+1 frame forwarding technology comes > along. > I agree. Best regards Sergio From nobody Mon Sep 14 22:21:00 2020 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 E62383A0DE6 for ; Mon, 14 Sep 2020 22:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 ILly1MA97bHy for ; Mon, 14 Sep 2020 22:20:44 -0700 (PDT) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (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 521E33A0DDE for ; Mon, 14 Sep 2020 22:20:44 -0700 (PDT) Received: by mail-ua1-x929.google.com with SMTP id j12so623278ual.7 for ; Mon, 14 Sep 2020 22:20:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=edeum7ImTvQe/ikyEGqTL3MzEyMobbgtQHRnuXVCFlM=; b=Q2BRHCwVIbfFSe74XNzM08vk2PZA8mjrHiDizIvsX7Q8Mb5UdYbMKWF0QoJG+BWO+x XH5w2o/LcC176uZ2T8YBihkBt8fQAz3N7+BwugaUn16Kxa5lZEqT4lwImSLuUkYZEOXQ 3kbCerGtYeXkqREVsGaKPXe/XPX91gBSbAcQ0uxbphDCCbAww5MED2kI06329dW7Tgz6 ypn2+/6qGBRS1kgASqql6LbXTRxRHHGwQH/pNmushT5N+dwSosnHXCpMt5rwAyeytAbm DCHAKi6Ddgpo+wE/rNYgsgvG30UPisABlo4lpbYxCz+hZxuq/VfFshNvJLQOTdBKVeUn ghvA== 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=edeum7ImTvQe/ikyEGqTL3MzEyMobbgtQHRnuXVCFlM=; b=opY3TVse2uZUWb60vxyUxvNQxcwvrJktCNxyHkDfLbhz4qnPTSU2F9Zf5qWW5ALIXW iHj8jmQkx8FprmWZvzqTLEnXSfxm35iPw/2BG94bDJiYDYKckesj+b1pocBFStEoq2+Y tCPxn7WYtTQ6ov3kQra8B7OGlZwXyjohYXnF/VgKPwfZJRM0z7KFK67KSFpzvfr4xoHf uVFl0g3l5gDSrOeeblBpi/KGnQR/XYXIVeT9Nm45ok8mHIYCnu9jljc6IBhvil87VLAo /c5R49lY6Y0C4y/iEnErsadn4W0ui9tJ+WtiT79YXuZRZn0EKwBxmE99gghvmbyfIZ5m Q4hg== X-Gm-Message-State: AOAM531TXjI1aNlK7u1aMQy4ysCubR4veNjKQ2IwbjnmirtHOFzg0rjE wiJzssm5kpOI+a/ViszLfa1pPbhoiJM+xeYwYoTV X-Google-Smtp-Source: ABdhPJzAcfYQeQh4gOZMZTIJM+EQrpwz/Sje/GYZ1wm+klt5bbvF5FEsB2XmqnuElfnvjB8Y3jYGgosUY/qIs0zyIy4= X-Received: by 2002:ab0:20b6:: with SMTP id y22mr8739939ual.30.1600147243122; Mon, 14 Sep 2020 22:20:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Emad Omara Date: Mon, 14 Sep 2020 22:20:30 -0700 Message-ID: To: Richard Barnes Cc: "Eric Vyncke (evyncke)" , DISPATCH , sframe@ietf.org, The IESG Content-Type: multipart/alternative; boundary="00000000000004413305af535040" Archived-At: Subject: Re: [Sframe] =?utf-8?q?=C3=89ric_Vyncke=27s_Block_on_charter-ietf-sf?= =?utf-8?q?rame-00-00?= X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2020 05:20:46 -0000 --00000000000004413305af535040 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Eric, Did Richard's responses address your concerns? Please let us know if you have more questions or concerns. Emad On Thu, Sep 10, 2020 at 7:28 AM Richard Barnes wrote: > Hi =C3=89ric, > > For some reason, your Block didn't get sent to the relevant mailing lists= , > so I'm crafting my own reply :) > > - 'Selection among multiple encryption keys' should there be a way to use >> different encryption algorithm as well with the encapsulation (I noted t= hat >> this bullet is explicitly for inside a session)? >> > > No. The assumption is that the algorithm is fixed for a given flow, but > there may be multiple keys (e.g., for different senders), and of course, > each encrypted unit needs a different nonce. We could add some text to > clarify this if you think it's really necessary, but this seems like a > finer level of granularity than is needed in a charter. > > >> - like Magnus, I find "Information to form a unique nonce" pretty vague >> and is it 'nonce' or more 'initialization vector' ? >> > > I've revised to be clear that the encapsulation has a standard nonce > formation algorithm, and the wire format provides the input to it. The > word "nonce" is standard here (see > https://tools.ietf.org/html/rfc5116#section-2.1) > > >> - 'This working group will not specify the signaling required to >> configure SFrame encryption", it is unclear to me whether the WG will >> specify a control channel to negotiate keys and crypto algorithms as the >> current sentence appears more generic configuration (e.g., supported cry= pto >> algorithms) >> > > No, the WG will not specify a control channel. That is something the > application will have to provide. > > >> - only one milestone ? There is nothing about the RTP mapping document >> that is mentioned in the charter text >> > > Yep. Just one thing, the encapsulation. The MLS mapping and RTP > considerations should both be small enough to be sections in that documen= t. > > --Richard > > > -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --00000000000004413305af535040 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eric,

Did Richard's responses ad= dress your concerns? Please let us know if you have more questions or conce= rns.

Emad

On Thu, Sep 10, 2020 at 7:28 AM Ric= hard Barnes <rlb@ipv.sx> wrote:
=
Hi =C3=89ric,

For some reason, your Block didn&= #39;t get sent to the relevant mailing lists, so I'm crafting my own re= ply :)

- 'Selection among multiple encryption keys' should there be= a way to use different encryption algorithm as well with the encapsulation= (I noted that this bullet is explicitly for inside a session)?

No.=C2=A0 The assumption is that the algorithm is = fixed for a given flow, but there may be multiple keys (e.g., for different= senders), and of course, each encrypted unit needs a different nonce.=C2= =A0 We could add some text to clarify this if you think it's really nec= essary, but this seems like a finer level of granularity than is needed in = a charter.
=C2=A0
- like Magnus, I find "Information to form a unique nonce&= quot; pretty vague and is it 'nonce' or more 'initialization ve= ctor' ?

I've revised to be clea= r that the encapsulation has a standard nonce formation algorithm, and the = wire format provides the input to it.=C2=A0 The word "nonce" is s= tandard here (see https://tools.ietf.org/html/rfc5116#section-2.1)
=C2=A0
- &#= 39;This working group will not specify the signaling required to configure = SFrame encryption", it is unclear to me whether the WG will specify a = control channel to negotiate keys and crypto algorithms as the current sent= ence appears more generic configuration (e.g., supported crypto algorithms)=

No, the WG will not specify a control = channel.=C2=A0 That is something the application will have to provide.
<= /div>
=C2=A0
- o= nly one milestone ? There is nothing about the RTP mapping document that is= mentioned in the charter text

Yep.=C2= =A0 Just one thing, the encapsulation.=C2=A0 The MLS mapping and RTP consid= erations should both be small enough to be sections in that document.
=

--Richard


--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--00000000000004413305af535040-- From nobody Mon Sep 14 22:53:41 2020 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 7C7BF3A0BB9; Mon, 14 Sep 2020 22:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=H176ZanI; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=u5vI9RhA 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 OWw3apWmzlKH; Mon, 14 Sep 2020 22:53:37 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 111893A0E6C; Mon, 14 Sep 2020 22:53:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14537; q=dns/txt; s=iport; t=1600149217; x=1601358817; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eXf4SGHvMNJ0Y/NyluIDFc3YrvtHvjlMiT1xYAN6e0Y=; b=H176ZanIeEArPZ7sTeGmObFGK5l1A4i/vH62EhHKGz3lIzTUiXaMKSdG jYhf3BwEdct/9SEGdE43SXCyMUH+JJMWqaLejPwbiaF19YS0MxICs+4V0 C3q7ScIq0KdwAx9V9xE2MphFlF0/p+sMVGXAftZ85sl+KbGVmx2K8gBu5 k=; IronPort-PHdr: =?us-ascii?q?9a23=3AUOAfVxyMOU/LxCjXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRSPt/R1khnSTdaT5/FFjr/QtKbtESwF7I2auX8POJpLS1?= =?us-ascii?q?ceiMoQkgBhZazNCUDyIPPwKSBvGsNEWQxk52/9KlgGUMr7bkfZ93u16zNaEx?= =?us-ascii?q?7jNA1zc+LyHIOaj8m+2+2ovZPJZAAdjzumarQ0JxKz/gg=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CFBwBkVmBf/4QNJK1gHgEBCxIMggQ?= =?us-ascii?q?LgSMvUQdwWS8shDmDRgONcJQEhG6BLoElA1ULAQEBDQEBIwoCBAEBhEsCF4I?= =?us-ascii?q?RAiQ1CA4CAwEBCwEBBQEBAQIBBgRthVwMhXIBAQEBAxIRHQEBLAsBDwIBCA4?= =?us-ascii?q?DAwECKwICAjAaAwgCBA4FIoMEAYF+TQMuAQ6rBAKBOYhhdoEygwEBAQWFOhi?= =?us-ascii?q?CEAMGgTiCcYNpgiaCaYEmHRuBQT+BESccgk0+glwBAQIBgXwNgmozgi2QD4M?= =?us-ascii?q?YhnCccwqCZYhxkU8DHqBthESYdJUOAgQCBAUCDgEBBYFWAjaBV3AVZQGCPlA?= =?us-ascii?q?XAg2OH4NxhRSFQnQCNQIGAQkBAQMJAXuPVAEB?= X-IronPort-AV: E=Sophos;i="5.76,428,1592870400"; d="scan'208,217";a="815883241" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Sep 2020 05:53:32 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 08F5rWLU007962 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Sep 2020 05:53:32 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 15 Sep 2020 00:53:32 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 15 Sep 2020 00:53:31 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 15 Sep 2020 00:53:31 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C15DlP5VC7AOxofQq6p1Xq1IscU/KrvbAFGra+Ye+GvDf+M3WuU2xNbUURHwwDOMEkYk5+1FU1uyc6izPGAq3iLIHbyjYpCzq7XoP7liMc+B1XKpert+ne4Mojr+vNBg3Ij0qkZug+gEkH69+0wpS7X3snPwK9uLASerGglRHn7y55gfkyNH17SNvYRxWjCkKAuzvG2+wSN3fv7MoO6ErFIYeWSgtnJwEl1fL2X+EJpPE669qMQYiB7tys655uAoqNHfY0hDjw9Pkr/R1BUjm6EedojG+f+yLCM97R6auOE2Rm8D8WY0fO/8jBkrcwAOVJGCZR2pxSu5Bb8ageK/LA== 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=eXf4SGHvMNJ0Y/NyluIDFc3YrvtHvjlMiT1xYAN6e0Y=; b=QUSUl/+moJXpbWfGEy4JeleNCNdMMFSUXoMjdXmxulFlCREZjwXiXSg93tY6fcta/JlNzhcTxk1/YYYjytmctoRNV/7/rzhiISm8qqc6zrlm9NKHbNw4ya7js03np8IkmJCm8z/VtBznkda1gtlQNLF5iKxeCByhWjgxUCrKHX4vh6naWLhqZa3VYWfnf/8eX1wEd2lZaAS666tKBPCUaafyL8eWcLQhxKoIiMJjOKAJ9Lw/b528d9kHubcYrMrz5YzTPyn/Mo0YZRl7cbTgK1e3CdlyKr6Dsqs/3swy8YaUdzaUAJu8mKgBihfSg+zah2CxSDOQjHxE7owEpYceIg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eXf4SGHvMNJ0Y/NyluIDFc3YrvtHvjlMiT1xYAN6e0Y=; b=u5vI9RhAl1pcJjKCamw4N1JHnicqk9HquvkdsAi228UZw7kRSRdn5v1Xt3tNYURyqkaE9XXnbXsAT2toFsdoyLy+iP+G3T3vSvwlHMp7FtNgnkTsr26XtTW0H/cDDeGiaSmymZ2+P+AGbJUGzY1NLH7KIrN81bLeQb/5UihpraQ= Received: from BN6PR11MB1844.namprd11.prod.outlook.com (2603:10b6:404:103::20) by BN6PR11MB0034.namprd11.prod.outlook.com (2603:10b6:405:6b::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.24; Tue, 15 Sep 2020 05:53:29 +0000 Received: from BN6PR11MB1844.namprd11.prod.outlook.com ([fe80::d525:a81a:74e0:12e7]) by BN6PR11MB1844.namprd11.prod.outlook.com ([fe80::d525:a81a:74e0:12e7%12]) with mapi id 15.20.3370.019; Tue, 15 Sep 2020 05:53:29 +0000 From: "Eric Vyncke (evyncke)" To: Richard Barnes CC: DISPATCH , "sframe@ietf.org" , "The IESG" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgQmxvY2sgb24gY2hhcnRlci1pZXRmLXNmcmFtZS0w?= =?utf-8?Q?0-00?= Thread-Index: AQHWh36duAaYmG3ptEWrbhiRtd6hkalpW5oA Date: Tue, 15 Sep 2020 05:53:29 +0000 Message-ID: <385163A7-A32D-48CF-B38E-A4D44253E33D@cisco.com> References: In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: ipv.sx; dkim=none (message not signed) header.d=none;ipv.sx; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:1c8d:b3b5:5e1c:1d8d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4c813498-7a84-4fcf-a5c9-08d8593bac12 x-ms-traffictypediagnostic: BN6PR11MB0034: 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: EPQR4DOIaF8lEpydwaETbEJs5BMQqnZ/hOWOWNeA9wXRiAJK2IppKDrA27H7Gt99syuciNXWWrFC5PEOxaJoP2llSKoOgwSqWE9S3cACGyqYYUsun3UtN3IRREvO6xNkNPRKUh9gqSqgOa0X/GMQof1ywb097ArfYYaR4e/qSCCa3yJDKKqebtmEIvujrawnK8W4DCBFi/8r0dOdjd2mW+vKWHczABz2u1awl4V9eT012lIo6LhH/gXDriKzTFxS7ZxNhVZgQas/KyVYp/015kJQ7X7InTSiHHqXnXQfs0Ljok9J0UWPjZOK6Q3ezNWCXDSwPiNANDMwnT1qBwuesqNjGkr793zQ/J2dROPXE7++1RmN1FPiyoSvn5HHymEHJ2gh42SFou8P8dKKnAHNIg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB1844.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(366004)(376002)(346002)(136003)(396003)(2616005)(186003)(6916009)(478600001)(966005)(2906002)(33656002)(54906003)(36756003)(316002)(224303003)(83380400001)(86362001)(4326008)(66574015)(76116006)(91956017)(66946007)(66476007)(64756008)(6512007)(8936002)(6506007)(53546011)(71200400001)(66446008)(66556008)(5660300002)(166002)(6486002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: r8lLd2jzLEH1yHFcgzq9lLmvMOfT6jpI0jWkwsYw560z3jUXVZAdt4l6PUabJas8lU2NTY2KcTWJ+cZwjJdbxW6+XMmzQkgOJiGn/LNxKCfwKxZz3ZdZE5qOD6lkbMZCE0y7ntYeESORF/vW8jKPxujIEbRyl645qWsqWw2VkH3UQFP9la6aH3fnldVUCVoNq0FNZd1hNFapRyn/591opBDh+UJVTyE046C32eg4zBEbUewULQW4pCHNKviyLMrIHRh6iHxtDiL1ZpcWgLRwzk0r2UbSLcjYBtdZ3wlgbQcuS+mGC16gxLE2OEtA9KOQd1NDz/0CY46S6F4uexCt70ccMBiZ83WIe9pQ9B/9E39zXnGCSX2D4HbvWJfP/ACPBSLv1eA4Pre+//n03VoN3/zXyOSl9iv9rNCwyndXGpu8meRQyFC4GWHlbkPd2nFS2Ni+9C3pouqzoeKSr3TA5oyrp6so5kdlx/vfRcgT8wLJLcOMGOc4J1tBOi524Gapu4/lQr8c/dm7cqyGDoZPU91lm9zNdFhas2szXZG6iGcoMUkO4dUTb6oUDCOi/K1MXg/1xNZTtLo8KS/3J65niwEZ+9bk5hkKmRDHEipW3vUpPvvn8ODfCHogLJE1ZklaqNTIGcQh6KnI8n8LQpiivEJaee2/Kgv0/PR0YW5NwjzoNrFCveJrh5qVDANVQNRZSfl5bL07UCjxbfSRT4KFZA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_385163A7A32D48CFB38EA4D44253E33Dciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN6PR11MB1844.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4c813498-7a84-4fcf-a5c9-08d8593bac12 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Sep 2020 05:53:29.5312 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wJ2iWo4MinZcCZzQqmqvFt5NTjRqLzSsEE+CmBIhLlqoR168G6p8XRG2bTclU1/YE/zg57ggICgfIe7R+7BTFg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB0034 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [Sframe] =?utf-8?q?=C3=89ric_Vyncke=27s_Block_on_charter-ietf-sf?= =?utf-8?q?rame-00-00?= X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2020 05:53:40 -0000 --_000_385163A7A32D48CFB38EA4D44253E33Dciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmljaGFyZA0KDQpTb3JyeSBmb3IgYmVsYXRlZCByZXBseSwgSSBhbSBlbmpveWluZyBzb21lIGRh eXMgb2ZmLg0KDQpBcyBJIGluIG15IEJMT0NLLCBpdCBpcyBtb3JlIGFib3V0IGJlaW5nIHJlYWxs eSBjbGVhciBpbiB0aGUgY2hhcnRlciB0aGFuIGhhdmluZyByZWFsIGlzc3VlcyB3aXRoIHRoZSBj aGFydGVyLg0KDQpTZWUgaW4tbGluZSBmb3IgRVY+DQoNCg0KDQpGcm9tOiBSaWNoYXJkIEJhcm5l cyA8cmxiQGlwdi5zeD4NCkRhdGU6IFRodXJzZGF5LCAxMCBTZXB0ZW1iZXIgMjAyMCBhdCAxNjoy OA0KVG86IEVyaWMgVnluY2tlIDxldnluY2tlQGNpc2NvLmNvbT4NCkNjOiBESVNQQVRDSCA8ZGlz cGF0Y2hAaWV0Zi5vcmc+LCAic2ZyYW1lQGlldGYub3JnIiA8c2ZyYW1lQGlldGYub3JnPiwgVGhl IElFU0cgPGllc2dAaWV0Zi5vcmc+DQpTdWJqZWN0OiDDiXJpYyBWeW5ja2UncyBCbG9jayBvbiBj aGFydGVyLWlldGYtc2ZyYW1lLTAwLTAwDQoNCkhpIMOJcmljLA0KDQpGb3Igc29tZSByZWFzb24s IHlvdXIgQmxvY2sgZGlkbid0IGdldCBzZW50IHRvIHRoZSByZWxldmFudCBtYWlsaW5nIGxpc3Rz LCBzbyBJJ20gY3JhZnRpbmcgbXkgb3duIHJlcGx5IDopDQoNCi0gJ1NlbGVjdGlvbiBhbW9uZyBt dWx0aXBsZSBlbmNyeXB0aW9uIGtleXMnIHNob3VsZCB0aGVyZSBiZSBhIHdheSB0byB1c2UgZGlm ZmVyZW50IGVuY3J5cHRpb24gYWxnb3JpdGhtIGFzIHdlbGwgd2l0aCB0aGUgZW5jYXBzdWxhdGlv biAoSSBub3RlZCB0aGF0IHRoaXMgYnVsbGV0IGlzIGV4cGxpY2l0bHkgZm9yIGluc2lkZSBhIHNl c3Npb24pPw0KDQpOby4gIFRoZSBhc3N1bXB0aW9uIGlzIHRoYXQgdGhlIGFsZ29yaXRobSBpcyBm aXhlZCBmb3IgYSBnaXZlbiBmbG93LCBidXQgdGhlcmUgbWF5IGJlIG11bHRpcGxlIGtleXMgKGUu Zy4sIGZvciBkaWZmZXJlbnQgc2VuZGVycyksIGFuZCBvZiBjb3Vyc2UsIGVhY2ggZW5jcnlwdGVk IHVuaXQgbmVlZHMgYSBkaWZmZXJlbnQgbm9uY2UuICBXZSBjb3VsZCBhZGQgc29tZSB0ZXh0IHRv IGNsYXJpZnkgdGhpcyBpZiB5b3UgdGhpbmsgaXQncyByZWFsbHkgbmVjZXNzYXJ5LCBidXQgdGhp cyBzZWVtcyBsaWtlIGEgZmluZXIgbGV2ZWwgb2YgZ3JhbnVsYXJpdHkgdGhhbiBpcyBuZWVkZWQg aW4gYSBjaGFydGVyLg0KDQpFVj4gT0ssIHRoZSB0ZXh0IGlzIHN0aWxsIHZhZ3VlIHRob3VnaCBh Ym91dCDigJxzZWxlY3Rpb27igJ0gYmVjYXVzZSBpdCBpcyBwcm9iYWJseSDigJxyb3RhdGlvbuKA nSBvciDigJxyZWZyZXNoaW5n4oCdDQoNCi0gbGlrZSBNYWdudXMsIEkgZmluZCAiSW5mb3JtYXRp b24gdG8gZm9ybSBhIHVuaXF1ZSBub25jZSIgcHJldHR5IHZhZ3VlIGFuZCBpcyBpdCAnbm9uY2Un IG9yIG1vcmUgJ2luaXRpYWxpemF0aW9uIHZlY3RvcicgPw0KDQpJJ3ZlIHJldmlzZWQgdG8gYmUg Y2xlYXIgdGhhdCB0aGUgZW5jYXBzdWxhdGlvbiBoYXMgYSBzdGFuZGFyZCBub25jZSBmb3JtYXRp b24gYWxnb3JpdGhtLCBhbmQgdGhlIHdpcmUgZm9ybWF0IHByb3ZpZGVzIHRoZSBpbnB1dCB0byBp dC4gIFRoZSB3b3JkICJub25jZSIgaXMgc3RhbmRhcmQgaGVyZSAoc2VlIGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM1MTE2I3NlY3Rpb24tMi4xKQ0KDQpFVj4gV2hpbGUgSSBrbm93IHdo YXQgYSBub25jZSBpcywgdGhlIHRleHQgd2lsbCBiZW5lZml0IG9mIGEgY2hhbmdlIG9mIHdvcmRp bmcNCg0KLSAnVGhpcyB3b3JraW5nIGdyb3VwIHdpbGwgbm90IHNwZWNpZnkgdGhlIHNpZ25hbGlu ZyByZXF1aXJlZCB0byBjb25maWd1cmUgU0ZyYW1lIGVuY3J5cHRpb24iLCBpdCBpcyB1bmNsZWFy IHRvIG1lIHdoZXRoZXIgdGhlIFdHIHdpbGwgc3BlY2lmeSBhIGNvbnRyb2wgY2hhbm5lbCB0byBu ZWdvdGlhdGUga2V5cyBhbmQgY3J5cHRvIGFsZ29yaXRobXMgYXMgdGhlIGN1cnJlbnQgc2VudGVu Y2UgYXBwZWFycyBtb3JlIGdlbmVyaWMgY29uZmlndXJhdGlvbiAoZS5nLiwgc3VwcG9ydGVkIGNy eXB0byBhbGdvcml0aG1zKQ0KDQpObywgdGhlIFdHIHdpbGwgbm90IHNwZWNpZnkgYSBjb250cm9s IGNoYW5uZWwuICBUaGF0IGlzIHNvbWV0aGluZyB0aGUgYXBwbGljYXRpb24gd2lsbCBoYXZlIHRv IHByb3ZpZGUuDQoNCkVWPiBXaGF0IGFib3V0IMKrIFRoaXMgd29ya2luZyBncm91cCB3aWxsIG5v dCBzcGVjaWZ5IHRoZSBzaWduYWxpbmcgcmVxdWlyZWQgdG8gZGVyaXZlIHRoZSBTRnJhbWUgZW5j cnlwdGlvbiBwYXJhbWV0ZXJz4oCdID8NCg0KLSBvbmx5IG9uZSBtaWxlc3RvbmUgPyBUaGVyZSBp cyBub3RoaW5nIGFib3V0IHRoZSBSVFAgbWFwcGluZyBkb2N1bWVudCB0aGF0IGlzIG1lbnRpb25l ZCBpbiB0aGUgY2hhcnRlciB0ZXh0DQoNClllcC4gIEp1c3Qgb25lIHRoaW5nLCB0aGUgZW5jYXBz dWxhdGlvbi4gIFRoZSBNTFMgbWFwcGluZyBhbmQgUlRQIGNvbnNpZGVyYXRpb25zIHNob3VsZCBi b3RoIGJlIHNtYWxsIGVub3VnaCB0byBiZSBzZWN0aW9ucyBpbiB0aGF0IGRvY3VtZW50Lg0KDQpF Vj4gT0ssIHRoZW4gdGhpcyBpcyBmaW5lDQotLVJpY2hhcmQNCg0KDQo= --_000_385163A7A32D48CFB38EA4D44253E33Dciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <1046CA3FF80E5F42B5DC44E5F5D0FF32@namprd11.prod.outlook.com> 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+DQo8Ym9keSBsYW5nPSJlbi1CRSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRlIiPlJpY2hhcmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlNvcnJ5IGZvciBiZWxhdGVkIHJl cGx5LCBJIGFtIGVuam95aW5nIHNvbWUgZGF5cyBvZmYuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BcyBJ IGluIG15IEJMT0NLLCBpdCBpcyBtb3JlIGFib3V0IGJlaW5nIHJlYWxseSBjbGVhciBpbiB0aGUg Y2hhcnRlciB0aGFuIGhhdmluZyByZWFsIGlzc3VlcyB3aXRoIHRoZSBjaGFydGVyLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+U2VlIGluLWxpbmUgZm9yIEVWJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlJpY2hhcmQgQmFybmVzICZsdDtybGJAaXB2LnN4Jmd0 Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgMTAgU2VwdGVtYmVyIDIwMjAgYXQgMTY6Mjg8 YnI+DQo8Yj5UbzogPC9iPkVyaWMgVnluY2tlICZsdDtldnluY2tlQGNpc2NvLmNvbSZndDs8YnI+ DQo8Yj5DYzogPC9iPkRJU1BBVENIICZsdDtkaXNwYXRjaEBpZXRmLm9yZyZndDssICZxdW90O3Nm cmFtZUBpZXRmLm9yZyZxdW90OyAmbHQ7c2ZyYW1lQGlldGYub3JnJmd0OywgVGhlIElFU0cgJmx0 O2llc2dAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPsOJcmljIFZ5bmNrZSdzIEJs b2NrIG9uIGNoYXJ0ZXItaWV0Zi1zZnJhbWUtMDAtMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5IaSDDiXJpYyw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Rm9yIHNvbWUgcmVh c29uLCB5b3VyIEJsb2NrIGRpZG4ndCBnZXQgc2VudCB0byB0aGUgcmVsZXZhbnQgbWFpbGluZyBs aXN0cywgc28gSSdtIGNyYWZ0aW5nIG15IG93biByZXBseSA6KTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LSAnU2VsZWN0aW9u IGFtb25nIG11bHRpcGxlIGVuY3J5cHRpb24ga2V5cycgc2hvdWxkIHRoZXJlIGJlIGEgd2F5IHRv IHVzZSBkaWZmZXJlbnQgZW5jcnlwdGlvbiBhbGdvcml0aG0gYXMgd2VsbCB3aXRoIHRoZSBlbmNh cHN1bGF0aW9uIChJIG5vdGVkIHRoYXQgdGhpcyBidWxsZXQgaXMgZXhwbGljaXRseSBmb3IgaW5z aWRlIGEgc2Vzc2lvbik/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij5Oby4mbmJzcDsgVGhlIGFzc3VtcHRpb24gaXMgdGhhdCB0aGUgYWxn b3JpdGhtIGlzIGZpeGVkIGZvciBhIGdpdmVuIGZsb3csIGJ1dCB0aGVyZSBtYXkgYmUgbXVsdGlw bGUga2V5cyAoZS5nLiwgZm9yIGRpZmZlcmVudCBzZW5kZXJzKSwgYW5kIG9mIGNvdXJzZSwgZWFj aCBlbmNyeXB0ZWQgdW5pdCBuZWVkcyBhIGRpZmZlcmVudCBub25jZS4mbmJzcDsgV2UgY291bGQg YWRkIHNvbWUNCiB0ZXh0IHRvIGNsYXJpZnkgdGhpcyBpZiB5b3UgdGhpbmsgaXQncyByZWFsbHkg bmVjZXNzYXJ5LCBidXQgdGhpcyBzZWVtcyBsaWtlIGEgZmluZXIgbGV2ZWwgb2YgZ3JhbnVsYXJp dHkgdGhhbiBpcyBuZWVkZWQgaW4gYSBjaGFydGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+RVYmZ3Q7IE9LLCB0aGUgdGV4dCBpcyBzdGlsbCB2YWd1ZSB0aG91Z2ggYWJvdXQg4oCcc2Vs ZWN0aW9u4oCdIGJlY2F1c2UgaXQgaXMgcHJvYmFibHkg4oCccm90YXRpb27igJ0gb3Ig4oCccmVm cmVzaGluZ+KAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij4tIGxpa2UgTWFnbnVzLCBJIGZpbmQgJnF1b3Q7SW5mb3JtYXRpb24gdG8gZm9ybSBhIHVuaXF1 ZSBub25jZSZxdW90OyBwcmV0dHkgdmFndWUgYW5kIGlzIGl0ICdub25jZScgb3IgbW9yZSAnaW5p dGlhbGl6YXRpb24gdmVjdG9yJyA/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5JJ3ZlIHJldmlzZWQgdG8gYmUgY2xlYXIgdGhhdCB0aGUg ZW5jYXBzdWxhdGlvbiBoYXMgYSBzdGFuZGFyZCBub25jZSBmb3JtYXRpb24gYWxnb3JpdGhtLCBh bmQgdGhlIHdpcmUgZm9ybWF0IHByb3ZpZGVzIHRoZSBpbnB1dCB0byBpdC4mbmJzcDsgVGhlIHdv cmQgJnF1b3Q7bm9uY2UmcXVvdDsgaXMgc3RhbmRhcmQgaGVyZSAoc2VlDQo8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTExNiNzZWN0aW9uLTIuMSI+aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzUxMTYjc2VjdGlvbi0yLjE8L2E+KTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+RVYmZ3Q7IFdoaWxlIEkga25vdyB3aGF0IGEgbm9uY2UgaXMsIHRoZSB0ZXh0 IHdpbGwgYmVuZWZpdCBvZiBhIGNoYW5nZSBvZiB3b3JkaW5nPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4tICdUaGlzIHdvcmtpbmcgZ3JvdXAgd2lsbCBu b3Qgc3BlY2lmeSB0aGUgc2lnbmFsaW5nIHJlcXVpcmVkIHRvIGNvbmZpZ3VyZSBTRnJhbWUgZW5j cnlwdGlvbiZxdW90OywgaXQgaXMgdW5jbGVhciB0byBtZSB3aGV0aGVyIHRoZSBXRyB3aWxsIHNw ZWNpZnkgYSBjb250cm9sIGNoYW5uZWwgdG8gbmVnb3RpYXRlIGtleXMgYW5kIGNyeXB0byBhbGdv cml0aG1zIGFzIHRoZSBjdXJyZW50DQogc2VudGVuY2UgYXBwZWFycyBtb3JlIGdlbmVyaWMgY29u ZmlndXJhdGlvbiAoZS5nLiwgc3VwcG9ydGVkIGNyeXB0byBhbGdvcml0aG1zKTxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Tm8sIHRoZSBX RyB3aWxsIG5vdCBzcGVjaWZ5IGEgY29udHJvbCBjaGFubmVsLiZuYnNwOyBUaGF0IGlzIHNvbWV0 aGluZyB0aGUgYXBwbGljYXRpb24gd2lsbCBoYXZlIHRvIHByb3ZpZGUuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5FViZndDsgV2hhdCBhYm91dCDCqyZuYnNwO1RoaXMgd29ya2luZyBncm91 cCB3aWxsIG5vdCBzcGVjaWZ5IHRoZSBzaWduYWxpbmcgcmVxdWlyZWQgdG8gZGVyaXZlIHRoZSBT RnJhbWUgZW5jcnlwdGlvbiBwYXJhbWV0ZXJz4oCdID88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPi0gb25seSBvbmUgbWlsZXN0b25lID8gVGhlcmUgaXMg bm90aGluZyBhYm91dCB0aGUgUlRQIG1hcHBpbmcgZG9jdW1lbnQgdGhhdCBpcyBtZW50aW9uZWQg aW4gdGhlIGNoYXJ0ZXIgdGV4dDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+WWVwLiZuYnNwOyBKdXN0IG9uZSB0aGluZywgdGhlIGVuY2Fw c3VsYXRpb24uJm5ic3A7IFRoZSBNTFMgbWFwcGluZyBhbmQgUlRQIGNvbnNpZGVyYXRpb25zIHNo b3VsZCBib3RoIGJlIHNtYWxsIGVub3VnaCB0byBiZSBzZWN0aW9ucyBpbiB0aGF0IGRvY3VtZW50 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RVYmZ3Q7IE9LLCB0aGVuIHRoaXMgaXMgZmlu ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPi0tUmljaGFyZDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_385163A7A32D48CFB38EA4D44253E33Dciscocom_-- From nobody Tue Sep 15 02:29:36 2020 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 D31873A0C4C; Tue, 15 Sep 2020 02:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.796 X-Spam-Level: X-Spam-Status: No, score=-3.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, 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=unavailable 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 Mzg3t1SPcmgW; Tue, 15 Sep 2020 02:29:26 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20047.outbound.protection.outlook.com [40.107.2.47]) (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 2347E3A0C48; Tue, 15 Sep 2020 02:29:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jZDDWGOSuj9yd8OIvmXktC/KHyNc4vbkshLUDto64e0NPj7hNpdbbDkxzMNzFm53hMOQG8deIKsPGQDqzRvp1mxNLWpZ+mIRcMyrQnYQg+AiSMibN6viO2UsJ/LyG2DHONpLyxNyhSzDBF69tiHqh0BoelEvgPFq7Mpy0kmcf1xRcWETAUzRa6wvNnjYB7WRXZvxkHFiJfiw121pVf+X4O5fzFbQjc8vvtbExUOaTcIQjv874bfRTXSETl0nDc/iJs5eB3+PbcTBHygQlbc4HwBZ32ufzBCJ5EIDCZ98Tct3bKKCdfVLnj4g5h3wm6LpjCx2wKrIlJKILlovgQ4JoQ== 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=bJrf3A1kG7v5V2b1HlpcKvp80CN20zySgcPOajq0OYc=; b=SDbfg2ZnlqtQpyCNdW2Izpu3FcfccMHtEDLrQtNahfNJi2Ck+SaoQ7TFusUr7IOo/mvDmYKijBjryzpySOBedeH/nJrCErWriG1LflI5Tw9sWR3w/SYPfKyjYwvLEUFyh6D2JHEXdl+R6WpaDjx5tuzaTn3nCs8sqQjWIdVD5WpFbOsuWRqwLPnDHHYGG2E0hfUPyp9K6GPo+LSl/qBMiC3pkJ6SM5FKv8cMRZsHB1pMTpleEBDrnsEv4BT92xZynsKbn5n4EDSbTY8KKoefG1I9wnAY08cJDGTbSC9/sYs0cK80w99lsJp/RA1hfLQ5ig+LUIB1DF/G91XevnmamQ== 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=bJrf3A1kG7v5V2b1HlpcKvp80CN20zySgcPOajq0OYc=; b=A5T3RAB9PZFmvso0gd7wW97D78xqE6j1mocJssvHo4BZ2kF8oNoWMRiG2nM0SXqny3OqZYqIewV52RoGb+7shLBxY/v4mKIEv7gRsVRic3ih1DxjSLZWqYNDlX0puvPHE7FvKyMeG5SIdXsE8CR5l47LXAI8rzKjEGmh/wu3nzg= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR07MB3097.eurprd07.prod.outlook.com (2603:10a6:7:32::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.4; Tue, 15 Sep 2020 09:29:13 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::c98a:9a0c:1eea:3fdc]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::c98a:9a0c:1eea:3fdc%6]) with mapi id 15.20.3391.009; Tue, 15 Sep 2020 09:29:13 +0000 From: Magnus Westerlund To: "bernard.aboba@gmail.com" , "sergio.garcia.murillo@gmail.com" CC: "sframe@ietf.org" , "dispatch@ietf.org" , "iesg@ietf.org" , "magnus.westerlund=40ericsson.com@dmarc.ietf.org" , "rlb@ipv.sx" , "sframe-chairs@ietf.org" , "sergio.garcia.murillo@cosmosoftware.io" Thread-Topic: [Sframe] [dispatch] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) Thread-Index: AQHWisdRmeX+RecTUkObteFi0teX5qloiP2A///HkQA= Date: Tue, 15 Sep 2020 09:29:12 +0000 Message-ID: <5a37f3e67efd750842cbccb17a46f50b8e2c2d43.camel@ericsson.com> References: <159949693494.2875.16993532753477402380@ietfa.amsl.com> <5c6c96621b29ebf4b1f84e53ae3a414c9d0ec3a5.camel@ericsson.com> <05085c6c-0c30-a407-8f41-b6c9be8100bc@gmail.com> <49b13e5efa0b2ac0a7b09842dbce8793dfcf6667.camel@ericsson.com> <10062d18-4e6b-fd76-eabd-9a746a7812fd@gmail.com> In-Reply-To: <10062d18-4e6b-fd76-eabd-9a746a7812fd@gmail.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2 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: [158.174.116.90] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 78f98dbc-67b0-4a15-ec85-08d85959cee6 x-ms-traffictypediagnostic: HE1PR07MB3097: 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: 1Aq3SIEADb6DasRk7Ft+O9i0Fo00bB72oLXu7Z8H7thh0f1B0HhpA7kLi6qu5wtiBJ7tRXICmD6nWYm7Nlo+CGAZXUwaGpcgoFbbw86Ys5cA+OKZO/7xvkz0HM5dqubxJajuEtAiE8XoZQ2gX0rupnmLMayp8DDWqtKwTXNvU1vI1nQZFb02vQN3TqOSDwfnC/JpOPwO4IPFsECxCMFEpPEYPN+WaAZiHnKjjP6MNsMPoiEu5FCK745AjTLsXf82PCg1BdTD+1Ef6zPXP6ze3bq5mb0CQLoRFbiJBvcGKR5tB/yvwTUQf5tsmEgtssZ0DCHBL0d3gsz6LhH05lSAZrKhv4DyjORDv6iQ/MKSYJY+wefpZxqBHYY4bqu7qUqr x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(366004)(39860400002)(136003)(346002)(396003)(66446008)(8676002)(66556008)(6512007)(110136005)(64756008)(8936002)(66946007)(54906003)(76116006)(2906002)(66476007)(4326008)(83380400001)(44832011)(86362001)(53546011)(5660300002)(186003)(6486002)(36756003)(26005)(6506007)(71200400001)(2616005)(478600001)(316002)(99106002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: wMV1qQ1AC3YBAo1YOV9mlldLKOv78Tf+RZlMWMAXcwgZkVnzOosWYR8WlL23QZ0dhNnFq64iAL9Fpden8G2A+0yAqcEudlf/aEa+3LR2YFSCZPIqTRa29Zn4e8+3wd9yoIdwXDWI9Up2QhZtRT8tkF6ENBB9scTf7DnLuH3Hejt9Nbo541Yb1S+Q1shKvCLBYPpm0r8ixBv29h7kZcf+EftEZPde4IKDEj+S/xQOlwQV+VkQaCTJpbJFYhRIFrQRSmqGNXvTlWzqDyRdmVUPA6JHfSeBXEQFVzAv6YMbRTJZkt28d+U1sXDCr54jUaiyYpSlKYpp3HXQuisvZNOsDT/Ux48Vq5UiHuq6glXLDyGfZjP9X/ypm3jOq3Ura+Gfexh51flRNdfmytKBHdHRg2emjuMCM9bmYQdMvPecxsfLqtq0kmmIiIPxvtgH5uzELLys5p3Ckms4Wnv/jdlTIWS+HfUxmp3TmERVI8LVhAXWCnFvQBXNc84yy7ktj0XMum1B+ni9CZt3/YmpN9L2L0lFiYUUxRvx4RMaZHcTDhfOKQG4mC6GR2mLw29HEb6HFf1FEGSSf9nEcPS8U1MR6Dk+nAi7nBA3rX+9NKO88TF9jXl7aDWrzyS3LR1o04aKujTLfIH9Nafoh0etDwC82Q== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 78f98dbc-67b0-4a15-ec85-08d85959cee6 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Sep 2020 09:29:13.0197 (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: 5biIa0BptevYxVgEbZZY5YLeqQNrlJa2bDMmNl3Zpb+BtLHjydBtbZpyFqvG698MQ0MS57LOf6ofV2/woQ1NCRXMR1ErqWHmxIWx4/llAjY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3097 Archived-At: Subject: Re: [Sframe] [dispatch] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2020 09:29:28 -0000 T24gTW9uLCAyMDIwLTA5LTE0IGF0IDIxOjQzICswMjAwLCBTZXJnaW8gR2FyY2lhIE11cmlsbG8g d3JvdGU6DQo+IE9uIDE0LzA5LzIwMjAgMjA6NDUsIEJlcm5hcmQgQWJvYmEgd3JvdGU6DQo+ID4g DQo+ID4gR2l2ZW4gdGhhdCB3ZSBkb24ndCBoYXZlIGEgbG90IG9mIGRlcGxveW1lbnQgb2YgZnJh bWUgZm9yd2FyZGluZyBSVFAgDQo+ID4gaGVhZGVyIGV4dGVuc2lvbnMgeWV0LCBpdCdzIHByb2Jh Ymx5IGJlc3QgdG8gYXZvaWQgdHlpbmcgU0ZSQU1FICB0byANCj4gPiBhbnkgcGFydGljdWxhciBk ZXNpZ24uICBGb3IgZXhhbXBsZSwgeW91IHdvdWxkbid0IHdhbnQgYSBkZXNpZ24gdGhhdCANCj4g PiBjb3VsZCBvbmx5IGZ1bmN0aW9uIHdpdGggdGhlIGZyYW1lbWFya2luZyBSVFAgaGVhZGVyIGV4 dGVuc2lvbiBvciB0aGUgDQo+ID4gR2VuZXJpYyBGcmFtZSBEZXNjcmlwdG9yIG9yIHRoZSBEZXBl bmRlbmN5IERlc2NyaXB0b3IsIHNvIHRoYXQgYSBuZXcgDQo+ID4gc3BlY2lmaWNhdGlvbiBpcyBu ZWVkZWQgd2hlbiB0aGUgTisxIGZyYW1lIGZvcndhcmRpbmcgdGVjaG5vbG9neSBjb21lcyANCj4g PiBhbG9uZy4NCj4gPiANCj4gDQoNCg0KRm9yIHRoaXMgYWxsIHBvaW50cyB0byB0aGF0IFNGUkFN RSBXRyBzaGFsbCBub3QgZG8gdGhlIFJUUCBQYXlsb2FkIGZvcm1hdCwNCmluc3RlYWQgdGhhdCB3 b3JrIHNoYWxsIGJlIGRvbmUgaW4gQVZUQ09SRSBXRy4gVGh1cywgZXZlcnl0aGluZyBmb3IgU0ZS QU1FIHRoYXQNCmhhcyB0byBkbyB3aXRoIFJUUCB3aWxsIGJlIGRlYWx0IHdpdGggaW4gQVZUQ09S RSBhbmQgdG8gbXkga25vd2xlZGdlIHRoaXMgaXMNCndpdGhpbiB0aGUgY2hhcnRlciBvZiBBVlRD T1JFLiBIb3dldmVyLCBtYXliZSB0aGUgU0ZSQU1FIGNoYXJ0ZXIgc2hvdWxkIGJlDQpleHBsaWNp dCBhYm91dCB0aGF0IHRoaXMgc2h1b2xkIGJlIG5vdGVkIGluIGEgcGFyYWdyYXBoIGluIHRoZSBT RlJBTUUgV0cgY2hhcnRlcg0KdGhhdCB0aGUgV0cgd2lsbCBjb2xsYWJvcmF0ZSBvbiB0aGlzIGFz cGVjdC4gQmVjYXVzZSBJIHdpbGwgYXNzdW1lIHRoYXQgdGhlcmUNCndpbGwgYmUgc29tZSBhc3Bl Y3RzIHRoYXQgd2lsbCBmbG93IGZyb20gdGhlIFJUUCBQYXlsb2FkIGZvcm1hdCB3b3JrIHRvd2Fy ZHMgdGhlDQpTRlJBTUUgZm9ybWF0LiANCg0KQ2hlZXJzDQoNCk1hZ251cyBXZXN0ZXJsdW5kIA0K DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCk5ldHdvcmtzLCBFcmljc3NvbiBSZXNlYXJjaA0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KRXJpY3Nzb24gQUIgICAgICAgICAgICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5 DQpUb3JzaGFtbnNnYXRhbiAyMyAgICAgICAgICAgfA0KU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dl ZGVuIHwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCg0KDQo= From nobody Tue Sep 15 02:47:09 2020 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 3D4FA3A0C64; Tue, 15 Sep 2020 02:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.796 X-Spam-Level: X-Spam-Status: No, score=-3.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, 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 RMKweOM7c6eQ; Tue, 15 Sep 2020 02:46:59 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70051.outbound.protection.outlook.com [40.107.7.51]) (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 6EF203A0C60; Tue, 15 Sep 2020 02:46:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kC3Wf3FUUEhklNclI/vA8X5eINKKzZgdbgTkMdC8zHq6wQ25feWvYfuRFhbgJjOqrAuGAyHSXaWZgR+wVL3M6CupUVxkmwmd4kWyyPgmNXTCjLOMGHQO/VRVb+9B4r9uv4+tbcaHIYstzLZz6jy5RxB9mgVjLqf48cSF/YxkSKUIXEawkl2d5CxqhhTuV23yt7Q2B/Xupbx+uuGrCPou3USwF4qrW36Iiu0/L+PqNuyko6jwmLlwvXvuNKARXHDu2WHjKmBUeJrUvqo7sUjXxx9y6we2dtWDcMLl9dH1TJRXn97AIAvlpX3MDhGHlTJNdJPzWXPJkThmCplz1B5zZw== 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=1bavODGNZvbYwhcT0GxebS/Pl775OXghrJL17kQuQKM=; b=aZX4gcvyO8s3m9wEkSuMvc7Q7TOwG7F20P1CrMlc+A6UshDWa4PZyQ4k9+islitmfbfcZePbmPPhZu2lhkGQSoCcYeaxNFeEmBG1JlljKBcpDwjhaOGqTOkJYd84HdY5MRYgCfSERvmqufrNZrTVBt1yV5grBm21eVUixsB1rcOsiIgmlv9QhSbboLGC9hwL0CJz0bkxr2SMzzHQJmI12e1PuceOUF+DCzQotZLtm0wAYx2KobfVXwuAJOQ0vQhV/fdh7zvRUoR8rELMoa6QmNFBlXKNwO8/y+9Al6NbuoEkWfu6nMVvE2TxxgIeBEASD3Xb+srx0cGwWYa+SDa9sw== 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=1bavODGNZvbYwhcT0GxebS/Pl775OXghrJL17kQuQKM=; b=HY4dvM3D5jMzZSTk7uy9PiakNsH33kOlgMyjyKDb3pjqV2RxR9BXhL2mnNIziPV1Txu6wtJr9WgDv6jx/O1MtMfJCs/NC2tBYMULpXQw3EeLWOdzpfe+cwa0G/IqxKtvSlXiQgqvEHZiFpmfABGOMCTIQEmXb2/OznJDIVr7/fA= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) 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.3391.5; Tue, 15 Sep 2020 09:46:55 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::c98a:9a0c:1eea:3fdc]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::c98a:9a0c:1eea:3fdc%6]) with mapi id 15.20.3391.009; Tue, 15 Sep 2020 09:46:55 +0000 From: Magnus Westerlund To: "sergio.garcia.murillo@cosmosoftware.io" , "rlb@ipv.sx" , "sergio.garcia.murillo@gmail.com" CC: "dispatch@ietf.org" , "iesg@ietf.org" , "sframe@ietf.org" Thread-Topic: [dispatch] [Sframe] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) Thread-Index: AQHWhTXfuLaYkFC4LEWqC8j5AGiLAKlh8DkAgAASwICAALgzgIAAV8mAgAAoYICAAA/A0IAAS+mAgAQwQoCAACQlgIAATFQAgAA2lgD///JUAA== Date: Tue, 15 Sep 2020 09:46:55 +0000 Message-ID: References: <159949693494.2875.16993532753477402380@ietfa.amsl.com> <5c6c96621b29ebf4b1f84e53ae3a414c9d0ec3a5.camel@ericsson.com> <05085c6c-0c30-a407-8f41-b6c9be8100bc@gmail.com> <49b13e5efa0b2ac0a7b09842dbce8793dfcf6667.camel@ericsson.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2 authentication-results: cosmosoftware.io; dkim=none (message not signed) header.d=none;cosmosoftware.io; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [158.174.116.90] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 03af180b-a23c-41e2-98fb-08d8595c480c 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: KybFNGRfW/dl2BAL9PWQOUqSSDh7uLuOAGEH9A8ceffj3x6Pb6+wQxm6+BVsQcbMru1fTORXbp77MqYB8nl9ZF3O01mhp7Ft57+KyxPJdYTzcw1z4SMC2hQelFD+OdnQhMRSZ+5lbQbRsRz4UjyV6TEYJyony4Pxt6XI3dNolbj4WVm4F8Nmzom2yJQajIg3IvfH8Eeh2pU3y5TRzEZ6kNtHYoomM/4t1NkfknPN3YOHIvmvMHnW+hQmEyDx8Wsxh92Rka3HRc8rKyjLKiwFXgjw2DxXZ0W0ksqmMUt6VFj04HTnX0BJmKex7EdK7tNYfYCuaEpEjHDGhhLPxw/6sGtF3uF2+f+ktimMDL0QabJGwZSQkqUtZo7Di2MpCL9fGQBcHIbZFgM0yx273KghNPxBfckmdDzEwinQLMHNKNg= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(376002)(39860400002)(366004)(346002)(36756003)(4326008)(316002)(478600001)(66476007)(64756008)(26005)(110136005)(6512007)(5660300002)(6506007)(66556008)(54906003)(76116006)(66946007)(66446008)(2616005)(71200400001)(6486002)(8676002)(44832011)(53546011)(2906002)(8936002)(83380400001)(186003)(86362001)(99106002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 3qwb9W0gbUEZ4G4wuR75jyHLMTuKaaXqKGV90dcyPs+c4uBJH8SNlLcdrEIcCTjGjGsZkPNg4dTLOML+k+TEhJDGuWuZjc04BGjJ84OBzfjJ3oIv37+3a0GaNT1WTR5BishiwMPmroOaCPxj6n2VYrS+/duMmZHFFxb7AnoM+wdYGXaN5darcp+c+jHhPiedubCiPKYU6r6r7UCjdW8V8nTeBfK+obWcB30UOYhPZ6+33tuQUWq5mBmL2xluUhdixs29iQqbx0b7gfh4EJm4lNjarOqFF74ZegLYtcrsXj+f1QnhLqxkZLOp1Zvr0W7xjmZb9/5lEd1ImdRVkdKSisTnNoOR8zBzCqQn+J1esrBx5vHeH5r5v2uzUdhjPXYoglJg5ycuqFsPJEqg9gfau2goGQo21lIsY4YmM8RFEgPdnWBLkux12yHnMjL/L+yf3xSPl1koQUZRFyri8SiTT88wrpRQb/I5B1D4f6GTEnQlfvUOT1E1Fg8rkIn4w1YYml24UmZXKO9VOtZFO1EqJ9vsbUK3D65VD96Z3cOj6s0Hi3pzwCRlate++DviYgTPAfFXbUeTQc0oHTZkuSIdNGZX6C8LZLCgWzWsA/0TFG8iTyNqQYnba+tB+VotI7Dfn61BOm2rkUWZZMXXUi+ovw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <4ABD2FCB66AA174FB27F06D7337FC8C0@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 03af180b-a23c-41e2-98fb-08d8595c480c X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Sep 2020 09:46:55.2694 (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: QyUEo29rsRhq4Vk+AtkC5I/j4BL1TyqTDNOYEeFuetK+mE4Vncj8y7CjpkZD+/t1XxB8AgLS+2rN9TBh4gYE2AfOsGwp89at+klQ/IniVAc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2459 Archived-At: Subject: Re: [Sframe] [dispatch] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2020 09:47:00 -0000 T24gTW9uLCAyMDIwLTA5LTE0IGF0IDE5OjI3ICswMjAwLCBTZXJnaW8gR2FyY2lhIE11cmlsbG8g d3JvdGU6DQo+IE9uIDE0LzA5LzIwMjAgMTY6MTIsIE1hZ251cyBXZXN0ZXJsdW5kIHdyb3RlOg0K PiA+IFNlcmdpbywNCj4gPiANCj4gPiBIYXZpbmcgMjAgeWVhcnMgb2YgZXhwZXJpZW5jZSB3aXRo IFJUUCBwYXlsb2FkIGZvcm1hdCBkZXNpZ25zIHNvbWUgb2YgeW91cg0KPiA+IGZvcm11bGF0aW9u cyBtYWRlIG1lIGEgYml0IHdvcnJpZWQuIEFmdGVyIHRoaXMgZGlzY3Vzc2lvbiBJIHRoaW5rIHdl IGFyZQ0KPiA+IG11Y2gNCj4gPiBjbG9zZXIgb24gYSBjb21tb24gdW5kZXJzdGFuZGluZyBvZiB0 aGUgaGlnaCBsZXZlbCBmdW5jdGlvbmFsaXR5IG5lY2Vzc2FyeS4gDQo+ID4gDQo+ID4gSG93ZXZl ciwgdGhlcmUgd2lsbCBiZSBxdWVzdGlvbnMgYWJvdXQgd2hlcmUgd2UgZG9jdW1lbnQgdGhhdCBp bnRlcmFjdGlvbg0KPiA+IGFuZA0KPiA+IHdoYXQgZGVwZW5kZW5jaWVzIHRoYXQgZG8gZXhpc3Qg b24gb3RoZXIgc3BlY2lmaWNhaXRvbnMgZm9yIHNjYWxhYmxlIGNvZGVjcw0KPiA+IHRoYXQNCj4g PiBhcmUgZ2VuZXJpYyBhbmQgaXMgZGVzaXJhYmxlIHRvIHJlcXVpcmUgZnJvbSBSVFAgbWlkZGxl Ym94ZXMuIEluIGFkZGl0aW9uDQo+ID4gZXZlbg0KPiA+IHdpdGhvdXQgUlRQIHRoZXJlIHdpbGwg YmUgbmVlZCBmcm9tIHRoZSBhcHBsaWNhdGlvbiB0byBjb25zaWRlciBob3cgaXQgY2FuDQo+ID4g dXRpbGl6ZSBvbmUgU0ZSQU1FIGtleSBhbmQgaXRzIElWcyB0byBjYXJyeSBtdWx0aXBsZSBhcHBs aWNhdGlvbiBzdWItc3RyZWFtcyANCj4gPiBhbmQNCj4gPiB0aGUgbmVlZCB0byBleHBvc2UgdGhh dCB0byBsb3dlciBsYXllciB0cmFuc3BvcnQgZnVuY3Rpb24gdG8gYWNoaXZldmUNCj4gPiBwZXJm b3JtYW5jZSBnb2Fscy4gDQo+IA0KPiBXaGF0IEkgZmFpbCB0byB1bmRlcnN0YW5kIGlzIHRoZSBu YXR1cmUgb2YgeW91ciBjb25jZXJucyBhbmQgaG93IHNob3VsZCB3ZQ0KPiBhZGRyZXNzIHRoZW0g b24gdGhlIGNoYXJ0ZXI6DQo+IElzIGl0IHNvbWV0aGluZyB0aGF0IHdlIHBsYW4gdG8gZG8gdGhh dCBpcyBub3QgY292ZXJlZCBpbiB0aGUgY2hhcnRlcj8NCj4gSXMgaXQgc29tZXRoaW5nIHRoYXQg d2UgZG9uJ3QgcGxhbiB0byBkbyBidXQgdGhlIGNoYXJ0ZXIgaXMgd2lkZSBlbm91Z2ggdG8NCj4g YWxsb3cgaXQ/DQo+IElzIGl0IHNvbWV0aGluZyB0aGF0IHdlIHBsYW4gdG8gZG8gYW5kIGl0IGlz IGNvdmVyZWQgaW4gdGhlIGNoYXJ0ZXIgYnV0IHlvdQ0KPiBkb24ndCBhZ3JlZSB0byBpdD8NCj4g SXMgaXQgc29tZXRoaW5nIHRoYXQgd2UgZG9uJ3QgcGxhbiB0byBkbyBhbmQgaXMgbmVpdGhlciBj b3ZlcmVkIGJ5IHRoZSBjaGFydGVyDQo+IGFuZCB3ZSBzaG91bGQgYWRkIGl0Pw0KDQpJIHRoaW5r IHdpdGggdGhlIHJlc29sdXRpb24gb2YgdGhlIFJUUCBwYXlsb2FkIGZvcm1hdCB0aGVyZSBpcyBv bmx5IHRoZSBxdWVzdGlvbg0KaWYgdGhlcmUgbmVlZHMgdG8gZXhpc3QgYW4gaW5mb3JtYXRpb25h bCBkaXNjdXNzaW9uIHRvd2FyZHMgdGhvc2Ugd2hvIGludGVuZGVkDQp0byBhcHBseSB0aGUgU0ZS QU1FIGZvcm1hdCBpbiB0aGVpciBhcHBsaWNhdGlvbiB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuDQph cHBsaWNhdGlvbiBzdHJlYW1zIG9yIHN0cnVjdXRyZXMgYW5kIHRoZSBTRlJBTUUgc2VxdWVuY2Ug YW5kIHRoZWlyIGtleXMgYW5kIHRoZQ0KcmVxdWlyZW1lbnQgdGhhdCBwdXRzIG9uIG1ldGEgZGF0 YSBhbmQgbWFwcGluZyB0byBsb3dlciBsYXllciB0cmFuc3BvcnQNCmRlcGVuZGluZyBvbiBhcHBs aWNhdGlvbi4gSSBkbyBub3RlIHRoYXQgYSBwdXJlIHN0b3JlIGFuZCBmb3J3YXJkIGFwcGxpY2F0 aW9uDQpsaWtlIGVtYWlsIGhhcyBpdHMgc2V0IG9mIG5lZWRzIHRoYXQgaXMgcXVpdGUgZGlmZmVy ZW50IGZyb20gcmVhbC10aW1lIG1lZGlhLiANCg0KSSBwZXJzb25hbGx5IHdvdWxkIGxpa2UgdG8g c2VlIGl0IHdyaXR0ZW4gaW50byB0aGUgY2hhcnRlciB0aGF0IHRoaXMgbmVlZHMgdG8gYmUNCmNv bnNpZGVyZWQuIEluIHRoZSBjdXJyZW50IGRyYWZ0IHVwZGF0ZSBJIHRoaW5rIHRoZXJlIHdvcmRp bmcgdGhhdCB3b3VsZCBpbXBseQ0KdGhhdCB0aGlzIG5lZWRzIHRvIGhhcHBlbi4gSG93ZXZlciwg ZGVwZW5kaW5nIG9uIGhvdyB0aGUgYmVsb3cgY2hhbmdlIGFyZSBkb25lDQp0aGlzIG1pZ2h0IGdl dCBsb3N0LiANCg0KQW4gYWx0ZXJuYXRpdmUgZm9yIHRoZSBXRyB0byBhY3R1YWxseSBlbnN1cmUg dGhhdCB0aGV5IGhhdmUgYSBzb2xpZCBkZXNjcmlwdGlvbg0KYW5kIGNvbXBvbmVudHMgdGhhdCBz b2x2ZSB0aGUgaXNzdWUgd291bGQgYmUgdG8gd3JpdGUgYW4gbm9uLXN0YW5kYXJkDQpkZXNjcmlw dGlvbiBvZiBob3cgU0ZSQU1FIHdvdWxkIGJlIHVzZWQgaW4gV2ViUlRDIG11bHRpLW1lZGlhIG11 bHRpLXBhcnR5IHdpdGgNClNGVSBjb25mZXJlbmNlIGFwcGxpY2F0aW9uICBhbmQgd2hhdCBpcyBu ZWVkZWQgdG8gbWFrZSBpdCB3b3JrLiBUaGVyZSBvbmUgY291bGQNCmRpc2N1c3MgdGhlIFdlYlJU QyBhcHBsaWNhdGlvbnMgY29udHJvbCBvdmVyIGhvdyB0aGUgbWVkaWEgc3RyZWFtcyBTRlJBTUUN CmVuY2Fwc3VhbHRpb24gYW5kIG1hcHBpbmcgb250byBSVFAgc3RyZWFtcyBpbXBhY3QgdGhlIHVu ZGVybHlpbmcgcmVwYWlyIHRvb2xzDQphbmQgU0ZVcyBvZiBXZWJSVEMgY29uZmVyZW5jZSBhcHBs aWNhdGlvbi4gDQoNCklmIHRoaW5ncyBhcmUgZG9uZSBjb3JyZWN0bHkgYWxsIHRoZSBjb21wb25l bnRzLCBTRlJBTUUsIFJUUCBQYXlsb2FkIGZvcm1hdCwgYW5kDQptZXRhIGRldGEgdHJhbnNwb3J0 IHdvdWxkIGV4aXN0IGluIHNwZWNpZmljYXRpb25zIG9mIHRoZWlyIG93biwgc28gdGhhdCBpdCBj b3VsZA0KYmUgdGhhdCBoaWdoIGxldmVsIGRlc2NyaXB0aW9uIG9mIGhvdyBhbiBXZWJSVEMgYXBw bGljYXRpb24gbWFrZXIgd291bGQgZ2V0IHRoaXMNCnRvIHdvcmsgYXZvaWRpbmcgdGhvc2UgcGl0 ZmFsbHMgdGhhdCB3aWxsIGV4aXN0Lg0KDQo+IA0KPiA+IFNvIEkgdGhpbmsgc29tZSBjbGFyaWZp Y2F0aW9uIG9uIHRoZSBSVFAgcGF5bG9hZCBmb3JtYXQgd29yaywgYW5kIGl0IHRoYXQgaXMNCj4g PiBnb2luZyB0byBoYXBwZW4gaW4gdGhlIFNGUkFNRSBXRy4gSWYgaGFwcGVuaW5nIGluIFNGUkFN RSBXRyBJIHdvdWxkIGxpa2UgdG8NCj4gPiBoYXZlDQo+ID4gYSBqb2ludCBXRyBMYXN0IGNhbGwg d2l0aCBBVlRDT1JFIFdHLiANCj4gDQo+IEkgcmFpc2VkIHRoYXQgcXVlc3Rpb24gYWxyZWFkeSBh IGNvdXBsZSBvZiB0aW1lcy4gSSBhbSBub3Qgc3VyZSB3aGF0IGlzIHRoZQ0KPiByb2xlIG9mIHRo ZSBTRlJBTUUgV0cgcmVnYXJkaW5nIHNwZWNpZnlpbmcgYSBuZXcgUlRQIGNvZGVjLWFnbm9zdGlj IHBheWxvYWQuDQo+IElNSE8gdGhpcyBXRyBzaG91bGQgY29sbGVjdCB0aGUgcmVxdWlyZW1lbnRz LCBtYXRjaCB0aGVtIHRvIGN1cnJlbnQNCj4gc3BlY2lmaWNhdGlvbnMsIGFuZCBpZiBhbnl0aGlu ZyBpcyBtaXNzaW5nLCBsaWFpc2Ugd2l0aCB0aGUgYXBwcm9wcmlhdGUgZ3JvdXBzDQo+IGluIG9y ZGVyIHRvIHByb2R1Y2UgdGhlIHNwZWNzIGJhc2VkIG9uIG91ciAgICAgICByZXF1aXJlbWVudHMu DQoNCkZpbmUsIGxldHMgbWFrZSBpdCBleHBsaWNpdCBpbiBhIHBhcmFncmFwaCBpbiB0aGUgU0ZS QU1FIFdHIGNoYXJ0ZXIgdGhhdCBBVlRDT1JFDQpXRyB3aWxsIGJlIHRoZSBwbGFjZSB0byBkbyB0 aGUgd29yayBvbiB0aGUgUlRQIFBheWxvYWQgZm9ybWF0IGFuZCB0aGUgV0dzIHdpbGwNCmNvbGFi b3JhdGUgb24gdGhpcy4gDQogDQpDaGVlcnMNCg0KTWFnbnVzIFdlc3Rlcmx1bmQgDQoNCg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KTmV0d29ya3MsIEVyaWNzc29uIFJlc2VhcmNoDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpF cmljc3NvbiBBQiAgICAgICAgICAgICAgICAgfCBNb2JpbGUgKzQ2IDczIDA5NDkwNzkNClRvcnNo YW1uc2dhdGFuIDIzICAgICAgICAgICB8DQpTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW4gfCBt YWlsdG86IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoN Cg== From nobody Mon Sep 28 15:30:17 2020 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 DF1FC3A143E for ; Mon, 28 Sep 2020 15:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 tAp1EQ5IR2jH for ; Mon, 28 Sep 2020 15:30:14 -0700 (PDT) Received: from mail-vk1-xa29.google.com (mail-vk1-xa29.google.com [IPv6:2607:f8b0:4864:20::a29]) (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 37CAF3A143D for ; Mon, 28 Sep 2020 15:30:14 -0700 (PDT) Received: by mail-vk1-xa29.google.com with SMTP id c63so1951235vkb.7 for ; Mon, 28 Sep 2020 15:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OmvVm0wGkgEBlAz+UXYmWo12R7M20Bvu2DH1fvA5//E=; b=Fh9emtLpmn8hatWETA7GydV2myo7btylrjmS8ytb6jBtMcEQDZcvPxJW4kMQ0Tle5h 4/+kYp00Ys5iCdXD1jS0WRLSofF5jAFm86/pfAXrcNwExvuiNDs0HnrshOcHWRfORctC e1JnpIH9MatusdTuvzCFW4+3DtZYq0DICGZh3J0OHh8wteWlYSBBCWydkb0D/gMxNmrd L/owtPx7i/PonlQ6d4aztIKFj5SREhzSLp4UHBKZkr8VjtmJpQOjsDuleQBATMfnZt8f v24uVnIGSukpGeV/USCdOtTovigz8zg5Nj1dJBKhNJzsPp7cLWAoIcMitTGiA/MBi2Wf 3zMw== 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=OmvVm0wGkgEBlAz+UXYmWo12R7M20Bvu2DH1fvA5//E=; b=HP1H90HnEn52TNKJF4z771XqjdJ1uTLoHMuLwM5hsSumsshGrQlAb/M6sGuX1A4U3B Y2oiigAy9jAxERiva/PAkNe629SSCEBKdm3eZnk1dnHoh/1lCTE9e2vBr0yrs1AzOhUa BF16qBJezEswr6OlpkFQIWDSGZfC5s7MU0QSnufmn+UZz1kdWVcyi2vQj+t3f35Zo+GR m28RHgYofIqri6NK4uyrWRhLctC8/jYTpTJykQHGIuwQ13PYHJBXvwvEN400toOTxttb UVwrIfdy0dIx1jhwhMPM5ZL7CDP0jEoviaezxRpHmT+j3ScE46Y9oetr/SjVXFZOmT65 WALw== X-Gm-Message-State: AOAM532RSMk5bRJSqnS7ikl5AiLqni5RCqNRno3HcjXIswi3pwqvV8lP S8nXhHdCSUvAlK0gDvHJGVdqAwh1s5I7wtdqjyRz X-Google-Smtp-Source: ABdhPJznyRn37am7WCaCKwh7T6uyYFWaoSXU5H1hdG2lbtZyZk+MFsudjLWthJWOyomHMVdGl9NYOOojNSnErVshH40= X-Received: by 2002:a1f:2d0c:: with SMTP id t12mr1151035vkt.0.1601332212713; Mon, 28 Sep 2020 15:30:12 -0700 (PDT) MIME-Version: 1.0 References: <159949693494.2875.16993532753477402380@ietfa.amsl.com> <5c6c96621b29ebf4b1f84e53ae3a414c9d0ec3a5.camel@ericsson.com> <05085c6c-0c30-a407-8f41-b6c9be8100bc@gmail.com> <49b13e5efa0b2ac0a7b09842dbce8793dfcf6667.camel@ericsson.com> In-Reply-To: From: Emad Omara Date: Mon, 28 Sep 2020 15:30:01 -0700 Message-ID: To: Magnus Westerlund Cc: "sergio.garcia.murillo@cosmosoftware.io" , "rlb@ipv.sx" , "sergio.garcia.murillo@gmail.com" , "dispatch@ietf.org" , "iesg@ietf.org" , "sframe@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b52aa205b0673573" Archived-At: Subject: Re: [Sframe] [dispatch] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2020 22:30:16 -0000 --000000000000b52aa205b0673573 Content-Type: text/plain; charset="UTF-8" Hi Magnus, Jumping late to this thread, just want to summarize the discussion and proposed changes to make sure we are all on the same page. 1. AVTCORE is the place to address any WebRTC changes (ie payload type, frame metadata ,packetization, etc) 2. SFrame charter needs to be changed to explicitly mention #1 3. SFrame doc needs to describe the integration point and changes with WebRTC in high level language as a guidance for the ATCORE work (I suggest doing so in a separate draft) Would these address your concerns so we can move forward? Please let me know if there is anything else I missed. Thanks Emad On Tue, Sep 15, 2020 at 2:47 AM Magnus Westerlund wrote: > On Mon, 2020-09-14 at 19:27 +0200, Sergio Garcia Murillo wrote: > > On 14/09/2020 16:12, Magnus Westerlund wrote: > > > Sergio, > > > > > > Having 20 years of experience with RTP payload format designs some of > your > > > formulations made me a bit worried. After this discussion I think we > are > > > much > > > closer on a common understanding of the high level functionality > necessary. > > > > > > However, there will be questions about where we document that > interaction > > > and > > > what dependencies that do exist on other specificaitons for scalable > codecs > > > that > > > are generic and is desirable to require from RTP middleboxes. In > addition > > > even > > > without RTP there will be need from the application to consider how it > can > > > utilize one SFRAME key and its IVs to carry multiple application > sub-streams > > > and > > > the need to expose that to lower layer transport function to achiveve > > > performance goals. > > > > What I fail to understand is the nature of your concerns and how should > we > > address them on the charter: > > Is it something that we plan to do that is not covered in the charter? > > Is it something that we don't plan to do but the charter is wide enough > to > > allow it? > > Is it something that we plan to do and it is covered in the charter but > you > > don't agree to it? > > Is it something that we don't plan to do and is neither covered by the > charter > > and we should add it? > > I think with the resolution of the RTP payload format there is only the > question > if there needs to exist an informational discussion towards those who > intended > to apply the SFRAME format in their application the difference between > application streams or strucutres and the SFRAME sequence and their keys > and the > requirement that puts on meta data and mapping to lower layer transport > depending on application. I do note that a pure store and forward > application > like email has its set of needs that is quite different from real-time > media. > > I personally would like to see it written into the charter that this needs > to be > considered. In the current draft update I think there wording that would > imply > that this needs to happen. However, depending on how the below change are > done > this might get lost. > > An alternative for the WG to actually ensure that they have a solid > description > and components that solve the issue would be to write an non-standard > description of how SFRAME would be used in WebRTC multi-media multi-party > with > SFU conference application and what is needed to make it work. There one > could > discuss the WebRTC applications control over how the media streams SFRAME > encapsualtion and mapping onto RTP streams impact the underlying repair > tools > and SFUs of WebRTC conference application. > > If things are done correctly all the components, SFRAME, RTP Payload > format, and > meta deta transport would exist in specifications of their own, so that it > could > be that high level description of how an WebRTC application maker would > get this > to work avoiding those pitfalls that will exist. > > > > > > So I think some clarification on the RTP payload format work, and it > that is > > > going to happen in the SFRAME WG. If happening in SFRAME WG I would > like to > > > have > > > a joint WG Last call with AVTCORE WG. > > > > I raised that question already a couple of times. I am not sure what is > the > > role of the SFRAME WG regarding specifying a new RTP codec-agnostic > payload. > > IMHO this WG should collect the requirements, match them to current > > specifications, and if anything is missing, liaise with the appropriate > groups > > in order to produce the specs based on our requirements. > > Fine, lets make it explicit in a paragraph in the SFRAME WG charter that > AVTCORE > WG will be the place to do the work on the RTP Payload format and the WGs > will > colaborate on this. > > Cheers > > Magnus Westerlund > > > ---------------------------------------------------------------------- > Networks, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Mobile +46 73 0949079 > <+46%2073%20094%2090%2079> > Torshamnsgatan 23 | > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > > -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --000000000000b52aa205b0673573 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Magnus,

Jumping late to this th= read, just want to summarize the discussion and proposed changes to make su= re we are all on the same page.

  1. AVTCORE is= the place to address any WebRTC changes (ie payload type, frame metadata ,= packetization, etc)
  2. SFrame charter needs to be changed to explicitl= y mention #1
  3. SFrame doc needs to describe the integration point and= changes with WebRTC in high level language as a guidance for the ATCORE wo= rk (I suggest doing so in a separate draft)
Would these addre= ss your concerns so we can move=C2=A0forward? Please let me know if there i= s anything else I missed.

Thanks
E= mad


On Tue, Sep 15, 2020 at 2:47 AM Magnus Westerlund &= lt;magnus.westerlund=3D40e= ricsson.com@dmarc.ietf.org> wrote:
On Mon, 2020-09-14 at 19:27 +0200, Sergio Garcia = Murillo wrote:
> On 14/09/2020 16:12, Magnus Westerlund wrote:
> > Sergio,
> >
> > Having 20 years of experience with RTP payload format designs som= e of your
> > formulations made me a bit worried. After this discussion I think= we are
> > much
> > closer on a common understanding of the high level functionality = necessary.
> >
> > However, there will be questions about where we document that int= eraction
> > and
> > what dependencies that do exist on other specificaitons for scala= ble codecs
> > that
> > are generic and is desirable to require from RTP middleboxes. In = addition
> > even
> > without RTP there will be need from the application to consider h= ow it can
> > utilize one SFRAME key and its IVs to carry multiple application = sub-streams
> > and
> > the need to expose that to lower layer transport function to achi= veve
> > performance goals.
>
> What I fail to understand is the nature of your concerns and how shoul= d we
> address them on the charter:
> Is it something that we plan to do that is not covered in the charter?=
> Is it something that we don't plan to do but the charter is wide e= nough to
> allow it?
> Is it something that we plan to do and it is covered in the charter bu= t you
> don't agree to it?
> Is it something that we don't plan to do and is neither covered by= the charter
> and we should add it?

I think with the resolution of the RTP payload format there is only the que= stion
if there needs to exist an informational discussion towards those who inten= ded
to apply the SFRAME format in their application the difference between
application streams or strucutres and the SFRAME sequence and their keys an= d the
requirement that puts on meta data and mapping to lower layer transport
depending on application. I do note that a pure store and forward applicati= on
like email has its set of needs that is quite different from real-time medi= a.

I personally would like to see it written into the charter that this needs = to be
considered. In the current draft update I think there wording that would im= ply
that this needs to happen. However, depending on how the below change are d= one
this might get lost.

An alternative for the WG to actually ensure that they have a solid descrip= tion
and components that solve the issue would be to write an non-standard
description of how SFRAME would be used in WebRTC multi-media multi-party w= ith
SFU conference application=C2=A0 and what is needed to make it work. There = one could
discuss the WebRTC applications control over how the media streams SFRAME encapsualtion and mapping onto RTP streams impact the underlying repair too= ls
and SFUs of WebRTC conference application.

If things are done correctly all the components, SFRAME, RTP Payload format= , and
meta deta transport would exist in specifications of their own, so that it = could
be that high level description of how an WebRTC application maker would get= this
to work avoiding those pitfalls that will exist.

>
> > So I think some clarification on the RTP payload format work, and= it that is
> > going to happen in the SFRAME WG. If happening in SFRAME WG I wou= ld like to
> > have
> > a joint WG Last call with AVTCORE WG.
>
> I raised that question already a couple of times. I am not sure what i= s the
> role of the SFRAME WG regarding specifying a new RTP codec-agnostic pa= yload.
> IMHO this WG should collect the requirements, match them to current > specifications, and if anything is missing, liaise with the appropriat= e groups
> in order to produce the specs based on our=C2=A0 =C2=A0 =C2=A0 =C2=A0r= equirements.

Fine, lets make it explicit in a paragraph in the SFRAME WG charter that AV= TCORE
WG will be the place to do the work on the RTP Payload format and the WGs w= ill
colaborate on this.

Cheers

Magnus Westerlund


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Mobile +46 73 0949079
Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--000000000000b52aa205b0673573-- From nobody Tue Sep 29 05:58:24 2020 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 1A4403A0C25; Tue, 29 Sep 2020 05:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.301 X-Spam-Level: X-Spam-Status: No, score=-3.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, 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=unavailable 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 ViGh1XHULB8u; Tue, 29 Sep 2020 05:58:11 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2043.outbound.protection.outlook.com [40.107.21.43]) (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 D7C013A0C22; Tue, 29 Sep 2020 05:58:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a53bThzodLKsSnOH6T1/xzQTsD/jtCB3byskI4q8ck6WByUciE9aq4hWlD/4U9K2Gq1PrXHLLCFjqQ4AnqOG4oovDSw6utBWbFuSUoAayOXUBXO7es+t85efb7EJrZIEKGzz1fyKCkeNexwRxruHawGAsCQ34dqLegxJ6ppnUfgW8rbWSY6xyNdUkjvtJPSwYKCtVh2xb+45q3kPwmx+HlzmTQ/Q7V5hVqh5Cbcw+1ewDMAXzhRJNMDQ8qny8sIDgKbXd6YdfBdJwR4zJk0eO3P2ToNo06l3VjYs38/TeeHEwDBrlt7jGvRR/L9W+8Xi7pbiQWamAjd6sPZ4Cdj/iQ== 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=NTHH3kP9qiXkdUTRw8nH5YHgITJYrkQ7JeHuPD30M7I=; b=bBbImhFSfb9OtlPh55zflBJHUYXzP8v4JQGo8NbyGYbm2pPQik6tQE6/jA7XouC4pGfkMhlMfccLXcdb492YL0/bmoMoT0XabcRJBuE0iitB2PUbKnb4LhqFNLYi/JMgE06YgvVp4Oa86v8lK35ukS0MNVRJTsNmQ+3RlTjRXr13RErKONf2rWEBhK7GeiOlAmq0uKlGTNNYpdeYrj+JavCzR4Uc6P11X53zdzAIM8TbxRWsmizWi7k/JueqTMamA2jvarLAStlDMtUtms1IkMSZBnkBlx1zbeZw8tRrJxzoFo8zUbK/ZrtN3hZwWhozI1ZXn3JV69L4xUZK0TOJJg== 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=NTHH3kP9qiXkdUTRw8nH5YHgITJYrkQ7JeHuPD30M7I=; b=LHmfD00whNiQb7FApkwMPkX6BNOyX/i/Yv1m97nFHlvUM63D6DsTfRpepBg9URMh+LyX78xnao3N6xTN7IX0zbkCw69YszmUnMM179uMsBPQpOmW2ANVkpr8CjFyGyIXyNsRUmCUTGpM5L64Dy9TbQ5qmEKk8zmJgMsLNpRZZBA= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR07MB3097.eurprd07.prod.outlook.com (2603:10a6:7:32::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.14; Tue, 29 Sep 2020 12:58:04 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::c98a:9a0c:1eea:3fdc]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::c98a:9a0c:1eea:3fdc%6]) with mapi id 15.20.3433.032; Tue, 29 Sep 2020 12:58:04 +0000 From: Magnus Westerlund To: "emadomara=40google.com@dmarc.ietf.org" CC: "sframe@ietf.org" , "dispatch@ietf.org" , "iesg@ietf.org" , "sergio.garcia.murillo@cosmosoftware.io" , "rlb@ipv.sx" , "sergio.garcia.murillo@gmail.com" Thread-Topic: [Sframe] [dispatch] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) Thread-Index: AQHWleb0ZHKPZQLJ7Uiui6zCURAJGal/lISA Date: Tue, 29 Sep 2020 12:58:04 +0000 Message-ID: References: <159949693494.2875.16993532753477402380@ietfa.amsl.com> <5c6c96621b29ebf4b1f84e53ae3a414c9d0ec3a5.camel@ericsson.com> <05085c6c-0c30-a407-8f41-b6c9be8100bc@gmail.com> <49b13e5efa0b2ac0a7b09842dbce8793dfcf6667.camel@ericsson.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [158.174.130.68] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 84f5381f-6265-413f-2e75-08d864774e1b x-ms-traffictypediagnostic: HE1PR07MB3097: 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: m7XnpQdFYzTV52GitbcmyWVL0tlOUBorTYwE9TvQqHAytXju639ggEyEINd6kVRD4m/kMIVHhn4YNKsH8Xjd3M38NmwYzGeUblRdNFVnV2bvyGV+zJ1DBV/PE521yALBvv7ZVUbZinGX/mL/DRZKUtmnK9sAQ8NZBGFuWFcoiSl8LBUsTeW9ySVeHoftXupt4YL5tz1vCczsJMQQ/XS4PgrVSeXNEaWRg51LT+nfKV0xWcdIkJPKKr2YP1cu1g03fkRB1qXRt/ctLlHLRk5v3bSibLoESoYQeEueZ78RQMixHxbQ9fOiedN9QSQmLGl0Gj6Xe2oroORpm9kN81Qc5Ftp8cjoec4IzfO+uKNxlt9+Xpsdg3TmZeo/Pj9Yclft x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(39860400002)(346002)(366004)(396003)(316002)(8936002)(6486002)(76116006)(66476007)(66946007)(86362001)(66556008)(6512007)(5660300002)(64756008)(4326008)(8676002)(66446008)(6506007)(54906003)(186003)(26005)(2616005)(36756003)(2906002)(71200400001)(478600001)(44832011)(99106002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: o3ZIIWk8WzKZ+xNMF7LlLQzJ+XMJbPXII4CJxMg8VZbkOGgBTlz6zDsLJb8dcLu03nS5vEJxSeQTNfqxCdTNt+UvAERWYEjSo47OoCDxYHNnTVoX2hz3zt3of2zoQgAMCAEnY+U7ljklQVUtIq4sdCibt0QBn4UTPwbc8VnzlEAiJQBZWs6TyhKtb6zKlCVSXqYCvC0KiyhOi8xG0luFWOz+RnfIyxIUGGaj9OeE8bvk/LalxqbV8pSWwo7Bo1MP/dblAsflzyWlZieHWYehIogPZYmVp8eLqlZ5mJ5NWK5xcow7StWlDRLNAxmERWxOnvnzOlaVJoQjzYRfky+jnMlXClQmXsxOV+oc+cSak39wRQSkXMiY9PEcN3Rm+asvf2CdwdisZOfte8A6sZtsaT+e0CvEn3rPNqT9hMi4mV6rA0gW0RjcXP3pYCdV+RA6OPm2td+wHdUmRkkt5u8LBIpXbcMDAFqN3XBZlj5Apci6zGybcao+8XWPm4xt96uMvtPsjPQ+RQGBKCrzuT0aMeI3x8JLsbXRSlZKIDDgoMws7TOcyvJ8XoFTfnCbIGoYSE8UWSHCcEDMSATao0oaxvlD1OCbgRuOLO7tThw5xISdRCJiaawEsM7FaEz2iO4XYpDnW00h99h4oDwlV36dgA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <02E7B9AE793F8B4F86783A18F210A88F@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 84f5381f-6265-413f-2e75-08d864774e1b X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2020 12:58:04.6035 (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: nPGXeszylgZ8KISl6ELmUB2i51BLlrlFf4dxlMYTxmBW0DYFwTgKAE+Qj10QfIyJgB/gABnKnRMceh2pH3kZNdjIRyMdnTMMx88eSgcpTuU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3097 Archived-At: Subject: Re: [Sframe] [dispatch] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2020 12:58:13 -0000 T24gTW9uLCAyMDIwLTA5LTI4IGF0IDE1OjMwIC0wNzAwLCBFbWFkIE9tYXJhIHdyb3RlOg0KPiBI aSBNYWdudXMsDQo+IA0KPiBKdW1waW5nIGxhdGUgdG8gdGhpcyB0aHJlYWQsIGp1c3Qgd2FudCB0 byBzdW1tYXJpemUgdGhlIGRpc2N1c3Npb24gYW5kDQo+IHByb3Bvc2VkIGNoYW5nZXMgdG8gbWFr ZSBzdXJlIHdlIGFyZSBhbGwgb24gdGhlIHNhbWUgcGFnZS4NCj4gDQo+IEFWVENPUkUgaXMgdGhl IHBsYWNlIHRvIGFkZHJlc3MgYW55IFdlYlJUQyBjaGFuZ2VzIChpZSBwYXlsb2FkIHR5cGUsIGZy YW1lDQo+IG1ldGFkYXRhICxwYWNrZXRpemF0aW9uLCBldGMpDQoNCkkgd291bGRuJ3QgbmVjZXNz YXJ5IHNheSB0aGF0IGFsbCB0eXBlIG9mIFdlYlJUQyBjaGFuZ2VzIGFyZSBpbiBzY29wZSBmb3IN CkFWVENPUkUuIEkgd2FzIHByaW1hcmlseSB0aGlua2luZyBhYm91dCB0aGUgUlRQIHBheWxvYWQg Zm9ybWF0IGFuZCBwb3RlbnRpYWxseSBhDQpuZXcgbWV0YSBkYXRhIGhlYWRlciBleHRlbnNpb24g Zm9yIHRoZSBzd2l0Y2hpbmcgZGVjaXNpb24gZm9yIFJUUCBwYWNrZXRzIHdpdGgNClNGUkFNRXMg aW4gdGhlbS4gDQoNCj4gU0ZyYW1lIGNoYXJ0ZXIgbmVlZHMgdG8gYmUgY2hhbmdlZCB0byBleHBs aWNpdGx5IG1lbnRpb24gIzENClllcyB0aGF0IHdvdWxkIGJlIGdvb2QuIA0KDQo+IFNGcmFtZSBk b2MgbmVlZHMgdG8gZGVzY3JpYmUgdGhlIGludGVncmF0aW9uIHBvaW50IGFuZCBjaGFuZ2VzIHdp dGggV2ViUlRDIGluDQo+IGhpZ2ggbGV2ZWwgbGFuZ3VhZ2UgYXMgYSBndWlkYW5jZSBmb3IgdGhl IEFUQ09SRSB3b3JrIChJIHN1Z2dlc3QgZG9pbmcgc28gaW4gYQ0KPiBzZXBhcmF0ZSBkcmFmdCkN Cg0KWWVzLCBJIHRoaW5rIHRoaXMgaXMgbW9yZSBhIGhpZ2ggbGV2ZWwgdXNlLWNhc2UgLyBhcmNo aXRlY3R1cmFsIGluZm9ybWF0aW9uYWwNCmRvY3VtZW50IHNvIHRoYXQgdGhlIG9uZSBjYW4gZW5z dXJlIHRoYXQgdGhlIHRlY2huaWNhbCBzb2x1dGlvbiBkbyBzdXBwb3J0IGtub3duDQphbmQgZGVz aXJlZCB1c2VzIGNhc2VzIG9mIFNGUkFNRS4NCg0KPiBXb3VsZCB0aGVzZSBhZGRyZXNzIHlvdXIg Y29uY2VybnMgc28gd2UgY2FuIG1vdmUgZm9yd2FyZD8gUGxlYXNlIGxldCBtZSBrbm93DQo+IGlm IHRoZXJlIGlzIGFueXRoaW5nIGVsc2UgSSBtaXNzZWQuDQoNClllcywgSSBiZWxpZWYgc28uIA0K DQogDQpDaGVlcnMNCg0KTWFnbnVzIFdlc3Rlcmx1bmQgDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KTmV0 d29ya3MsIEVyaWNzc29uIFJlc2VhcmNoDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpFcmljc3NvbiBBQiAgICAg ICAgICAgICAgICAgfCBNb2JpbGUgKzQ2IDczIDA5NDkwNzkNClRvcnNoYW1uc2dhdGFuIDIzICAg ICAgICAgICB8DQpTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW4gfCBtYWlsdG86IG1hZ251cy53 ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg== From nobody Tue Sep 29 07:38:12 2020 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 7920F3A0E82; Tue, 29 Sep 2020 07:38:04 -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 SnCqZzMDV1EZ; Tue, 29 Sep 2020 07:38:03 -0700 (PDT) Received: from mail-vk1-xa30.google.com (mail-vk1-xa30.google.com [IPv6:2607:f8b0:4864:20::a30]) (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 2EBCA3A0E87; Tue, 29 Sep 2020 07:38:03 -0700 (PDT) Received: by mail-vk1-xa30.google.com with SMTP id e5so2494564vkm.2; Tue, 29 Sep 2020 07:38:03 -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=zEq3hGTVKtDA7DGHsVPpp9JLeMHOarViuazOdbNOnOc=; b=McCmLttRODk4HTWbkIEWt/1HnyMlgcLm6JVWiCTLlG9EZjIYiyrW5u70QxR1zts8K5 6N+VlFtsX7sy1KBIpu7G27ak2yaOd5Z8DEHwNDM1Y8iASre+Qy7rLFPz0MyIZqUgHwEy jnQvebyE0K4SdV0KQMg1YbNsJPoo8w66K/aQdb+jmMhy8yPhVftM/m3FMNaA4DKzAaA+ nX7Q8W+zo5iFnxzho/xCWoITg4dTIYg0nDooWynO3a3pG5Qj5/FYeg9NBuFnE/ORS3CM OYfUE8d3JeThNZUixX0Ku9nZEB3hz7vW1uhLk47NRqBB4thDO1ArWpVkETb1tPECx0t9 bg2w== 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=zEq3hGTVKtDA7DGHsVPpp9JLeMHOarViuazOdbNOnOc=; b=V443gl/LYFu+S5CH4Xp7/KerQbZ9k0faXVjrrE+oP+vypJYMhGr4t4LkiOSscaMUZq tRrRm5ucJx5rTWDjXWiujZrLeaWHorEG3kS64xneByjc9EyiO3n5/+vLQurEiAYlSy+p 6CVMXa0liXd5Fft2CAWaqxvfICj78OHURI/7y8gvidMxK29iYr7lZYHhKX4fehsRHzG7 d7+oEIaMY0SBLThb8wxTew85zszY5Fgg9ZDrHZdduGuV6p28j4oarcLwr74JyXJ5WDl0 mijcpQoGNEezsSofe5F6reghTcCh9P5bbBaiGdhjb6qDnm6f/0icLv7oJAsPZK9pGyI9 MeCg== X-Gm-Message-State: AOAM533kJW/bZPTxvodSzi1RvODN86tttbgfsWVBxyGdrjin9UT3qQKF aLbrSv8OCBIEQyBTbnq2GrS/9IWcoc4M8upLUwg= X-Google-Smtp-Source: ABdhPJwNCeFr0Qg3w27M9pjJP/g3jXhVxEXSMRe4nSlJ19FcZRzF78+rkdMVNzkhaLLN8aDFLmyiATw5qHqSuqrtGhc= X-Received: by 2002:a1f:434b:: with SMTP id q72mr2771555vka.5.1601390281825; Tue, 29 Sep 2020 07:38:01 -0700 (PDT) MIME-Version: 1.0 References: <159949693494.2875.16993532753477402380@ietfa.amsl.com> <5c6c96621b29ebf4b1f84e53ae3a414c9d0ec3a5.camel@ericsson.com> <05085c6c-0c30-a407-8f41-b6c9be8100bc@gmail.com> <49b13e5efa0b2ac0a7b09842dbce8793dfcf6667.camel@ericsson.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Tue, 29 Sep 2020 07:37:49 -0700 Message-ID: To: Magnus Westerlund Cc: "emadomara=40google.com@dmarc.ietf.org" , "dispatch@ietf.org" , "sframe@ietf.org" , "rlb@ipv.sx" , "sergio.garcia.murillo@gmail.com" , "iesg@ietf.org" , "sergio.garcia.murillo@cosmosoftware.io" Content-Type: multipart/alternative; boundary="000000000000e5227c05b074ba39" Archived-At: Subject: Re: [Sframe] [dispatch] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2020 14:38:05 -0000 --000000000000e5227c05b074ba39 Content-Type: text/plain; charset="UTF-8" On Tue, Sep 29, 2020 at 5:58 AM Magnus Westerlund wrote: > > Would these address your concerns so we can move forward? Please let me > know > > if there is anything else I missed. > > Yes, I belief so. > OK, then please let me know when the github version has been updated, and I'll copy it into the datatracker for the IESG to see. -MSK --000000000000e5227c05b074ba39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Sep 29, 2020 at 5:58 AM Magnus We= sterlund <magnus.westerlund=3D40ericsson.com@dmarc.ietf.org> wrote:
> Would t= hese address your concerns so we can move forward? Please let me know
> if there is anything else I missed.

Yes, I belief so.

OK, then please let = me know when the github version has been updated, and I'll copy it into= the datatracker for the IESG to see.

-MSK
--000000000000e5227c05b074ba39--