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

Sergio Garcia Murillo <sergio.garcia.murillo@cosmosoftware.io> Fri, 11 September 2020 02:25 UTC

Return-Path: <sergio.garcia.murillo@cosmosoftware.io>
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 <sframe@ietfa.amsl.com>; 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 <sframe@ietfa.amsl.com>; 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 <sframe@ietf.org>; Thu, 10 Sep 2020 19:25:25 -0700 (PDT)
Received: by mail-wm1-x335.google.com with SMTP id y15so3291847wmi.0 for <sframe@ietf.org>; 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 <magnus.westerlund=40ericsson.com@dmarc.ietf.org>, "rlb@ipv.sx" <rlb@ipv.sx>
Cc: "sframe-chairs@ietf.org" <sframe-chairs@ietf.org>, "dispatch@ietf.org" <dispatch@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "sframe@ietf.org" <sframe@ietf.org>
References: <159949693494.2875.16993532753477402380@ietfa.amsl.com> <CAL02cgS=y7mBt10n+jCGwUoy54eeH9ZXFijQdDSKk5Qt9mNrUw@mail.gmail.com> <e0b5dc1c04ab6b5cee2c88b5b1b348d7c70a5d4c.camel@ericsson.com>
From: Sergio Garcia Murillo <sergio.garcia.murillo@cosmosoftware.io>
Message-ID: <a3fbe87c-d60b-23f1-2968-c7ac6ad50ea4@cosmosoftware.io>
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: <e0b5dc1c04ab6b5cee2c88b5b1b348d7c70a5d4c.camel@ericsson.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/sframe/6ZlgAj2NcEu7Oa-5HktPab8CIWA>
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: 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