[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: https://datatracker.ietf.org/doc/charter-ietf-sframe/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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.
- [Sframe] Magnus Westerlund's No Objection on char… Magnus Westerlund via Datatracker