Re: [Fud] Charter Text

Olaf Bergmann <> Thu, 10 August 2017 16:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 44CD51323A4 for <>; Thu, 10 Aug 2017 09:16:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6eDPlSi7IAVH for <>; Thu, 10 Aug 2017 09:16:02 -0700 (PDT)
Received: from ( [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BF36C13239E for <>; Thu, 10 Aug 2017 09:16:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v7AGFuCP006368; Thu, 10 Aug 2017 18:15:56 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 3xStXr5C6mzDKwP; Thu, 10 Aug 2017 18:15:56 +0200 (CEST)
From: Olaf Bergmann <>
To: Hannes Tschofenig <>
Cc: Emmanuel Baccelli <>,
References: <> <> <> <> <> <>
Date: Thu, 10 Aug 2017 18:15:56 +0200
In-Reply-To: <> (Hannes Tschofenig's message of "Thu, 10 Aug 2017 13:47:36 +0200")
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Fud] Charter Text
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: FUD - Firmware Updating Description <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Aug 2017 16:16:04 -0000

Hi Hannes,

Hannes Tschofenig <> writes:

> FWIW I would not consider VoIP phones in scope of the devices we would
> be looking at.

I do not say that we should look at VoIP phones in general (if they
happen to be class 1 devices, they might be in focus here). I brought
these up as an example that shows how multi-step firmware updates today
are handled on devices that also have certain limitations on their RAM
and flash memory.

This brings me back to the charter text. It says:

  "Since the publication of RFC 4108 more than 10 years have passed and
   more experience with IoT deployments have lead to additional
   functionality requiring the work done with RFC 4108 to be revisited."

Now, although it was already suggested (and you agreed) to mention RFC
7228 class 1 devices later in the charter, the quoted sentence may lead
to the impression that this is merely a 4108bis which would address
non-constrained devices as well.

> I also recall discussions at the IoTSU workshop but I remember that
> there was some confusion between the concept of a monolithic firmware
> images and what is actually sent over the wire (full image vs.
> differential updates). I don't think we ever talked about bootloaders
> vs. the rest of the OS.

It's never too late to start. As said before: Vendors do this already.