[Sframe] Magnus Westerlund's No Objection on charter-ietf-sframe-00-02: (with COMMENT)

Magnus Westerlund via Datatracker <noreply@ietf.org> Tue, 13 October 2020 07:22 UTC

Return-Path: <noreply@ietf.org>
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 17C4D3A0EC3; Tue, 13 Oct 2020 00:22:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Magnus Westerlund via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: sframe-chairs@ietf.org, sframe@ietf.org, dispatch@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.20.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <160257375965.19700.2194558246070562506@ietfa.amsl.com>
Date: Tue, 13 Oct 2020 00:22:40 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sframe/5rzhDtkoJjKkVc1Lg0WxcaFhdxo>
Subject: [Sframe] Magnus Westerlund's No Objection on charter-ietf-sframe-00-02: (with COMMENT)
X-BeenThere: sframe@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 13 Oct 2020 07:22:40 -0000

Magnus Westerlund has entered the following ballot position for
charter-ietf-sframe-00-02: 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:


Thanks, this update address my significant issues with the charter.

I think the charter might be giving a slightly skewed image of the granularity
question. To my understanding the application data units (ADU) combined with
SFRAMEs properties and the underlying transport will in combination define what
granularity that are practical to accomplish. As an example an RTP payload
format for SFRAMEs that would support multiple SFRAME objects for a set of ADUs
belonging to the same video frame would provide great flexibility in how many
SFRAMEs the ADUs are protected in. If each ADU is split into multiple SFRAMES
that could be supported but maybe unnecessary as the codec likely are unable to
process sub-ADUs, at the same time putting multiple ADUs into one SFRAME
requires a seperation to exist above SFRAMEs. This type of questions will be
application specific and dependent on underlying layers where to support which
functionality. I have the impression that the proponents for SFRAME have a
desire to have minimal support for this in SFRAME and rather rely on how the
application and the transport is capable of applying SFRAMEs to achieve its
confidentiality goals.