Re: [Fud] Comment on draft-moran-fud-manifest-00

"Thomas Eichinger" <thomas@riot-os.org> Tue, 19 September 2017 23:59 UTC

Return-Path: <thomas@riot-os.org>
X-Original-To: fud@ietfa.amsl.com
Delivered-To: fud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3FA7133011 for <fud@ietfa.amsl.com>; Tue, 19 Sep 2017 16:59:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 JdKspuVannjJ for <fud@ietfa.amsl.com>; Tue, 19 Sep 2017 16:59:55 -0700 (PDT)
Received: from mail.stillroot.org (mail.stillroot.org [176.9.132.253]) by ietfa.amsl.com (Postfix) with ESMTP id F417C132944 for <fud@ietf.org>; Tue, 19 Sep 2017 16:59:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.stillroot.org (Postfix) with ESMTP id D1E5D42F6C; Wed, 20 Sep 2017 01:59:23 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at ba.stillroot.org
Received: from mail.stillroot.org ([127.0.0.1]) by localhost (mail.stillroot.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIHVY9ruyIfx; Wed, 20 Sep 2017 01:59:17 +0200 (CEST)
Received: from [192.168.1.66] (unknown [IPv6:2602:306:36e3:3580:1d7a:6a27:c0ff:e24f]) by mail.stillroot.org (Postfix) with ESMTPSA id A94084269D; Wed, 20 Sep 2017 01:59:16 +0200 (CEST)
From: "Thomas Eichinger" <thomas@riot-os.org>
To: "Hannes Tschofenig" <hannes.tschofenig@gmx.net>
Cc: fud@ietf.org
Date: Tue, 19 Sep 2017 16:59:14 -0700
Message-ID: <9A771B0B-A182-4C29-B283-99B8282560FA@riot-os.org>
In-Reply-To: <eb247364-e4d6-1c22-c882-0e53df6c2902@gmx.net>
References: <C64FB690-1EB9-46A0-989F-DAC57E1CA819@riot-os.org> <eb247364-e4d6-1c22-c882-0e53df6c2902@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (2.0BETAr6090)
Archived-At: <https://mailarchive.ietf.org/arch/msg/fud/uOEnxjoe5rM82N7ip2edDd11M0I>
Subject: Re: [Fud] Comment on draft-moran-fud-manifest-00
X-BeenThere: fud@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: FUD - Firmware Updating Description <fud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/fud>, <mailto:fud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/fud/>
List-Post: <mailto:fud@ietf.org>
List-Help: <mailto:fud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fud>, <mailto:fud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Sep 2017 23:59:57 -0000

Hi Hannes,

First, I'm sorry for the massive latency.

I'd be ok with having it as an optional feature but maybe bound to an 
optional textual description.
Meaning if you provide a textual description also provide a machine 
readable classification or only a classification one or neither. What do 
you think?

Totally agree with you regarding certification and regulation. The 
proposed addition in my opinion just allows for a wider variety of 
update strategies while some others might just ignore it.

Best,
Thomas


On 22 Aug 2017, at 4:33 PDT(-0700), Hannes Tschofenig wrote:

> Hi Thomas,
>
> interesting idea.
>
> As an optional feature I don't see a problem with it.
>
> How exactly the approval process for applying a firmware update in a
> particular product looks like will of course vary a lot. At the IOTSU
> workshop we had people describing a healthcare setting where any code
> changes need to go through certification first. In smart home
> environments the firmware updates are most likely facing fewer
> regulatory restrictions.
>
> Ciao
> Hannes
>
>
>
> On 08/11/2017 12:37 AM, Thomas Eichinger wrote:
>> Hi,
>>
>> reading draft-moran-fud-manifest-00 I am wondering what people think 
>> about
>> adding a component to the manifest classifying the described update 
>> as a
>> security and/or feature update (others are imaginable) in a 
>> machine-readable
>> manner.
>>
>> The use case I see is that users then can define rules to deploy 
>> security
>> only updates in an automated timely fashion while being able to 
>> review
>> others before. Similar to Directive.applyImmediately but not forced 
>> by the
>> Author of the update.
>>
>> Any opinions on that?
>>
>> Best,
>> Thomas
>>
>> _______________________________________________
>> Fud mailing list
>> Fud@ietf.org
>> https://www.ietf.org/mailman/listinfo/fud
>>