Re: [Sframe] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT)

Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 10 September 2020 15:26 UTC

Return-Path: <magnus.westerlund@ericsson.com>
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 <magnus.westerlund@ericsson.com>
To: "rlb@ipv.sx" <rlb@ipv.sx>
CC: "dispatch@ietf.org" <dispatch@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "sframe-chairs@ietf.org" <sframe-chairs@ietf.org>, "sframe@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: <e0b5dc1c04ab6b5cee2c88b5b1b348d7c70a5d4c.camel@ericsson.com>
References: <159949693494.2875.16993532753477402380@ietfa.amsl.com> <CAL02cgS=y7mBt10n+jCGwUoy54eeH9ZXFijQdDSKk5Qt9mNrUw@mail.gmail.com>
In-Reply-To: <CAL02cgS=y7mBt10n+jCGwUoy54eeH9ZXFijQdDSKk5Qt9mNrUw@mail.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: 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: <HE1PR0702MB36279A968B597498D77C745E95270@HE1PR0702MB3627.eurprd07.prod.outlook.com>
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: <E4322B6492B6F042BB73E406A7A5CC21@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: 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: <https://mailarchive.ietf.org/arch/msg/sframe/R7EwDBQYamuPUwWYXpma6n_e6eI>
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: <sframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sframe>, <mailto:sframe-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sframe/>
List-Post: <mailto:sframe@ietf.org>
List-Help: <mailto:sframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sframe>, <mailto:sframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Sep 2020 15:26:14 -0000

Hi,

I have now read Sergio and Bernards discussion on the Dispatch list. By dropping
it down to only dispatch I missed that discussion. 

On Thu, 2020-09-10 at 10:18 -0400, Richard Barnes wrote:
> 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.

Let me clarify what I see as the issue with the charter. 

So the whole point is to ensure that you can move SFRAMEs without any RTP. Thus,
what I was trying to exemplify through the previous work in RTP is to be able to
do this SFRAME do require meta data that enables a handling function to seperate
layers and dependecies. To support this I think you end up i the need for
extensible meta data, data that is unencrypted but strong considerd to avoid
information leakage and have good security properties. Taking the regular RTP
payload format headers straight may not be the best fit for many codecs.  If
that is going to be generic you end up in a naming and strucutre discussion like
what ended up in the Taxonomy RFC and like for the frame marking RTP header
extension.

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. 

> 

https://docs.google.com/document/d/10rG8nAR0U6cBBPffzXnLaPPYL4uzxYViAvgiSezoa7o/edit?usp=sharing
> 

I think the edits are an improvement solving several unclarities around the
other issues I raised.

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? 

Cheers

Magnus Westerlund 


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