Re: [dispatch] Stephen Farrell's Yes on charter-ietf-cellar-00-00: (with COMMENT)

"Ben Campbell" <ben@nostrum.com> Mon, 26 October 2015 19:29 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBC31B516C for <dispatch@ietfa.amsl.com>; Mon, 26 Oct 2015 12:29:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
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 KA3i2D_BpPvI for <dispatch@ietfa.amsl.com>; Mon, 26 Oct 2015 12:29:03 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 4255E1B5143 for <dispatch@ietf.org>; Mon, 26 Oct 2015 12:23:43 -0700 (PDT)
Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9QJNfBw091911 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 26 Oct 2015 14:23:42 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10]
From: Ben Campbell <ben@nostrum.com>
To: Michael Niedermayer <michael@niedermayer.cc>
Date: Mon, 26 Oct 2015 14:23:54 -0500
Message-ID: <98E2EBE2-4580-4A12-A77C-FAE69185F171@nostrum.com>
In-Reply-To: <20151022211948.GS4556@nb4>
References: <20151022133935.26487.12997.idtracker@ietfa.amsl.com> <2D88BA7A-6B89-465E-91FC-4FB6DC422434@nostrum.com> <CAOXsMFJY-EPt3u91Qy7A8Zf2OXt6_Y7pF4KWCMVxjXpi3J2_Jg@mail.gmail.com> <20151022211948.GS4556@nb4>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.2r5141)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dispatch/E2F60HjnYPMq1I2KFyi6Vkx5DIg>
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [dispatch] Stephen Farrell's Yes on charter-ietf-cellar-00-00: (with COMMENT)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Oct 2015 19:29:04 -0000

On 22 Oct 2015, at 16:19, Michael Niedermayer wrote:


[...]

>>>>
>>>> I wonder is there any interest in the security of the archived
>>>> stuff here, and whether the WG would want to possibly take
>>>> that on, most likely later. I'm not saying they should, as that
>>>> could be a lot of possibly contentious work, but if they did
>>>> want to do it, it'd be good to say in the charter.
>>
>> Does he mean security as in only allowing certain people to access 
>> the
>> data ? IMO it's out of the scope and better handled out of the file
>> format/streaming. It's more a transport/storage issue than format.
>>
>> There is encryption possible in WebM though that's working with a EME
>> DRM module.
>> http://www.webmproject.org/docs/webm-encryption/
>>
>
>> If he means data safety, that's something we can work on. We already
>> have the CRC for checking. In the past we also discussed redundancy
>> but it was ruled out (again, better handled outside of the file
>> format).
>
> forward error correction, that is to add redundancy to recover from
> damaged or lost parts of an archived file or stream/track, is
> something that sounds interresting. CRCs also exist at the video 
> stream
> (FFv1) layer. Theres currently no means to restore lost frames, slices
> or disk sectors except through concealing them based on previous
> frames. The existing CRCs are sufficient though to correct rare bit
> errors, if that occurs in any actual use case.
> Adding some layer of protection to protect from damaged or unreadable
> disk sectors or other larger damges losslessly is possible and
> interresting. Iam not sure at which layer that would be best to do
> though.

For the record, I think Stephen was asking more about confidentiality 
than about error correction.

Do you think anything relative to error correction needs to be added to 
the charter? It seem to me that is something that could be added in a 
future recharter if people think something becomes needed beyond the 
currently planned work.

Ben.