Software updates work (Was: Re: [97all] Reflections from IETF 97)

IETF Chair <> Wed, 11 January 2017 14:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 42834129EF7 for <>; Wed, 11 Jan 2017 06:37:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.9
X-Spam-Status: No, score=-2.9 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YHslUk9WfqLW; Wed, 11 Jan 2017 06:37:20 -0800 (PST)
Received: from [IPv6:2a00:1d50:2:101:6457:368:53a4:deb4] (unknown [IPv6:2a00:1d50:2:101:6457:368:53a4:deb4]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 880DC129EE7; Wed, 11 Jan 2017 06:37:17 -0800 (PST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Software updates work (Was: Re: [97all] Reflections from IETF 97)
From: IETF Chair <>
In-Reply-To: <>
Date: Wed, 11 Jan 2017 16:37:14 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Dave Dolson <>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <>
Cc: IETF Discussion <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Jan 2017 14:37:22 -0000

Dave Dolson asked me a question, and (with permission) I wanted
to respond on the public list, since the topic is probably interesting
for others as well.

> I'm reflecting on this statement:
> "At the very least, I think it would be beneficial for the IETF community to continue to call attention to folks that the minimum bar when introducing a large number of devices (or any device) to the Internet includes things like automatic software updates and avoiding default passwords. "
> I'm probably showing my ignorance, but is there any kind of standard for automatic software updates?
> As far as I know, this is an area reinvented by every development team.
> And It is also an area of pitfalls and land mines.
> I did find this: , but it is unclear to me if more work will be done.
> Should the IETF specify protocols and design patterns for software updates?
> I see this as relevant to everything from routers to browsers, video games and automobiles, not just IOT devices.
> Thanks for any thoughts you might provide,

Yes, it is relevant for many things.

We do have RFC 4108, but I don’t know how widely it is used. And of
course many of the other generic tools that the IETF has worked on
can be applied to the software update case.

I think additional software components, standards, and industry
consolidation on their usage would be helpful. But like so many
other things, the need and the will to use some of the existing
or new things needs to come from the those build the stuff.
Software updates are also somewhere between systems engineering
and communications; the IETF hasn’t done that much work on
systems engineering. Nevertheless, the push for work has to
come from the community.

Do we have people who believe there are unmet needs, and
would be willing to work to address those? What specific things
would you like to work on? Should we have a working group?
And as noted before, January would be a perfect time to start
talking about that :-)


P.S. I should also say that my original statement — specifying a
minimum bar, broader than software updates — is potentially
controversial. The IETF is primary about producing stuff that
people want to use; we’ve had limited success in commanding
people to use <important technology> by merely listing it as
a requirement. People will use what they will use. One might
classify the suggested minimum bar as wishful thinking, and
that IETF resources would be better spent on building those
missing software update standards or other pieces of tech.

The reason why I had a different opinion in this case was not
so much the direct ability to influence, but rather the indirect
effect that we might have for instance if people affected by 
attacks, insurers, governments, etc. would be able to point 
to an IETF document and say that not even the minimum
bar was met :-) But opinions will certainly differ on this.

There’s also a category between issuing requirements
and working on new tech, documenting state of the
art and missing pieces/challenges; that is always
useful. The IAB workshop on software updates was
in that category. The document from the workshop
is out: