From nobody Sun Oct 1 00:21:12 2017 Return-Path: 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 69FC3134472 for ; Sun, 1 Oct 2017 00:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 UscFdxjJXcgP for ; Sun, 1 Oct 2017 00:21:09 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 0388B132F2C for ; Sun, 1 Oct 2017 00:21:09 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id u128so1286408vkg.10 for ; Sun, 01 Oct 2017 00:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=aNDIQcvBaZ4raGDhAtMfF0B6UfXLCq7hf2hhAulLQOg=; b=X1D+DU5H2RsFXrK6iN8f+jaWRo2Oi21nhcHZiq7lcB3A4TIENW3c3hOeBlPmGrHv1i 4WqITjRMr4x/VrM9rriTT3Pa9WaSdyeEAj1/6khLIsN+AS2QwOiqeVmI3M1cLDr+3F1e zhWxsjyF2mycsp6f1xJDX3qf7TaHSMYgpkNuLPE7xYtJliKQU356+3dXwHbQimHC3UIx 3VkiLoKPq72RjNng6t1zxd31YSooUviHDSDTHwSwqX7wzg/5Jvo3ldtuTKJlNdlee8aj ogwLNJ5TeHd2cyVfcUtTFwYF0/Lr9vGqn5d1AkrSEGq0Oi0SbyYw7OWNjVqXTXL8EQgM djYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=aNDIQcvBaZ4raGDhAtMfF0B6UfXLCq7hf2hhAulLQOg=; b=nYMKb06jPSA4pNZos9ZBf1C0f5yKxaMiUZzFlTCld4MEhLzVR0eS6CrkedTNFEUSwp HgPeddp8JjSmcAjQ2UUhwLTDpkb+YIJ/yjUnf+vP28/glWxrXasp09zfl7Sk0h1mFPgN MR517sqb9jKM8V6Ze5oglgRbXehrFIoA7yTJtB3l495QkzfexxVPqo4eUqJUzpT1YYis pKTXoS4y4d/RGtQsmjUFgrVoeKhM4XWc44vY76FVD9x7Md8HaCx3EDoh1z8A44mmFDya mxkby4bBohPV0yluOvZttLEpmpChIQ8X0D1oyL+ZvnTZUUixY04Oe2PP/KtXlv3GFbGi OdOw== X-Gm-Message-State: AHPjjUgi7KXdxpstlnVgro53/v2HS9oQPOD7nnGYCWttgmJ7/7R5KsS5 M+8Etw2r6D6UwXmq9FVZTXQdaiqFYcm2nimpChq9dw== X-Google-Smtp-Source: AOwi7QBlxbTMgXBok/Fd2CPWgsHMSpINAzPZ0++orVqIe+gVD536eBHQNQISMt4W5Z+404hawhypj6rmcG+1HUa2ogY= X-Received: by 10.31.194.209 with SMTP id s200mr5641935vkf.136.1506842467865; Sun, 01 Oct 2017 00:21:07 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.176.83.109 with HTTP; Sun, 1 Oct 2017 00:20:47 -0700 (PDT) In-Reply-To: References: From: Emmanuel Baccelli Date: Sun, 1 Oct 2017 09:20:47 +0200 X-Google-Sender-Auth: hvww04_0HwGjpNAcfRT0o3wytC0 Message-ID: To: fud@ietf.org Content-Type: multipart/alternative; boundary="001a11439ec4079a4e055a771a19" Archived-At: Subject: Re: [Fud] Editorial Charter Update X-BeenThere: fud@ietf.org 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: Sun, 01 Oct 2017 07:21:10 -0000 --001a11439ec4079a4e055a771a19 Content-Type: text/plain; charset="UTF-8" Hi Hannes, thanks for the update. Reads well in my opinion. A couple of comments below: On Fri, Sep 29, 2017 at 1:00 PM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > > > Firmware Updating Description (FUD) > [Alternative proposal: SUIT (Software Updates for Internet of Things).] > > To no surprise, I really like SUIT, but if the WG focuses only on firmware and excludes other types of software updates, we should probably keep that name for another working group ;) On the other hand, FUD is still a problematic name. How about an alternative such as: FiDeL : Firmware Description for Low-end IoT devices out of scope are > software update solutions that aim to take the features of scripting > languages, such as JavaScript variants like JerryScript, into account. > FYI JerryScript is fully compliant with ECMA5.1, hence not really a "variant". Here, I don't think we need to be that precise anyway to get the message across. How about rephrasing with something like: "Software update solutions that target updating software other than the firmware binary (e.g. updating scripts) are out of scope". Cheers Emmanuel --001a11439ec4079a4e055a771a19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Hannes,

thanks for the update. Reads= well in my opinion.=C2=A0
A couple of comments below:

On Fri, Sep 29, 2017 a= t 1:00 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:


Firmware Updating Description (FUD)
[Alternative proposal: SUIT (Software Updates for Internet of Things).]


To no surprise, I really like SUIT, bu= t if the WG focuses only on firmware and excludes other types of software u= pdates, we should probably keep that name for another working group ;)

On the other hand, FUD is still a problematic name. Ho= w about an alternative such as:

FiDeL : Firmware D= escription for Low-end IoT devices


<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa= dding-left:1ex"> out of scope are
software update solutions that aim to take the features of scripting
languages, such as JavaScript variants like JerryScript, into account.
<= /blockquote>

FYI JerryScript is fully compliant with ECM= A5.1, hence not really a "variant".
Here, I don't t= hink we need to be that precise anyway to get the message across.
How about rephrasing with something like:

"S= oftware update solutions that target updating software other than the firmw= are binary (e.g. updating scripts) are out of scope".

Cheers

Emmanuel
=C2=A0
--001a11439ec4079a4e055a771a19-- From nobody Sun Oct 1 07:11:37 2017 Return-Path: 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 AA0EE1344C9 for ; Sun, 1 Oct 2017 07:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=phosphorus-io.20150623.gappssmtp.com 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 KFd0cmd9ZQlT for ; Sun, 1 Oct 2017 07:11:34 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 E95DC134973 for ; Sun, 1 Oct 2017 07:11:33 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id w63so3205611qkd.10 for ; Sun, 01 Oct 2017 07:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=phosphorus-io.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=VKSJWNjmdxpmlpYKiL/DbtehJSEAChW+TscawH5ATjY=; b=zjvPhTi3OQ3grIxAPd1ak0hO7GKbGiVLqVNdYsG7qBToDpuDpc19zXcT8Q97vpUt/9 vDbyIzTqtKLZhAKveZmwJtUv+ganWLK9J7qq1XHJ3WHhZnh1JTrui1R8kovGEuNjhv0X 1/LttOt+0xiN0zEyJ45OcV/2yrTBMRwlxTCIfIAUcuGdS+GBiu6L9eiQE3gQBYgSXnWc j2UAInHH7UoyaUtDrR98Qubkw1fj7c4A4xKyPJpvvTC93tVDTdbLtavy/4CAc4Yn+YfE a77NAP6t95KngnsSQJdPYo3mANvC6wj5vHpz7f3i59dygrhMzwSRePDDm8y/pFSg3K/C bEMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=VKSJWNjmdxpmlpYKiL/DbtehJSEAChW+TscawH5ATjY=; b=GLA5iQ8Y8pDgHs9hjV+AQweB2RrweLHTUytPvjtg1yXmNvNevV9pbAFJt+6REAgyRX 7yIjrKRwd6FB8eefvNmeiMLj6SSTCzJJnwKL6S8o0fwlKMKAE9XhBybFRXdeWCb2MQVN pfqLc5XmCs61sB0+OXczqnEWePYq8VMktHKuq27QCpNe60ho6X/Vhx98HvaIE51zVoC3 RYtd20waovqakL5yM5VkQDHkE6auKpWv+3ZF979BYGnTSqKbSQ/n22KzfZfBXF41j4t3 L96Gd3wTmo1RkCdNm7ms/LAG3ygj4ldaoOFzugnOk/mjG4iJlTD33WwDGMVdiWxVppAE AwsA== X-Gm-Message-State: AMCzsaWZ3ZNN/hdqCXxyWXVEojtIv7uMS8BhknLR4m9YqOrkuUfoJdY1 9zqql+DF+al86o99fk72ZbSD5NCZt5g= X-Google-Smtp-Source: AOwi7QCzpcXx+AW0h5nNbjEwQxEcmqsW252NNNBjaR2eRcy7VJZIFi45lxa94TLN+MsgZlVn1BQ2wA== X-Received: by 10.55.144.5 with SMTP id s5mr11549500qkd.63.1506867092752; Sun, 01 Oct 2017 07:11:32 -0700 (PDT) Received: from [10.10.10.1] ([12.152.225.232]) by smtp.gmail.com with ESMTPSA id n89sm4265632qkl.62.2017.10.01.07.11.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Oct 2017 07:11:31 -0700 (PDT) From: Chris Rouland Content-Type: multipart/alternative; boundary="Apple-Mail=_FD9C0A42-D6BB-431F-B989-C196AAC3BFC8" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 1 Oct 2017 10:11:29 -0400 References: To: fud@ietf.org In-Reply-To: Message-Id: <8E6DE4EA-ADC8-434D-9BFD-87AFE2387DCE@phosphorus.io> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Fud] Editorial Charter Update X-BeenThere: fud@ietf.org 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: Sun, 01 Oct 2017 14:11:36 -0000 --Apple-Mail=_FD9C0A42-D6BB-431F-B989-C196AAC3BFC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I do think that locking into the firmware binary itself could exclude a = significant part of the problem set around updating embedded IOT = operating systems that would not technically be classified as FW. I think SUIT is good and broad. -Chris > On Oct 1, 2017, at 3:20 AM, Emmanuel Baccelli = wrote: >=20 > Hi Hannes, >=20 > thanks for the update. Reads well in my opinion.=20 > A couple of comments below: >=20 > On Fri, Sep 29, 2017 at 1:00 PM, Hannes Tschofenig = > wrote: >=20 >=20 > Firmware Updating Description (FUD) > [Alternative proposal: SUIT (Software Updates for Internet of = Things).] >=20 >=20 > To no surprise, I really like SUIT, but if the WG focuses only on = firmware and excludes other types of software updates, we should = probably keep that name for another working group ;) >=20 > On the other hand, FUD is still a problematic name. How about an = alternative such as: >=20 > FiDeL : Firmware Description for Low-end IoT devices >=20 >=20 > out of scope are > software update solutions that aim to take the features of scripting > languages, such as JavaScript variants like JerryScript, into account. >=20 > FYI JerryScript is fully compliant with ECMA5.1, hence not really a = "variant". > Here, I don't think we need to be that precise anyway to get the = message across. > How about rephrasing with something like: >=20 > "Software update solutions that target updating software other than = the firmware binary (e.g. updating scripts) are out of scope". >=20 > Cheers >=20 > Emmanuel > =20 > _______________________________________________ > Fud mailing list > Fud@ietf.org > https://www.ietf.org/mailman/listinfo/fud --Apple-Mail=_FD9C0A42-D6BB-431F-B989-C196AAC3BFC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi,

I do think that locking into the = firmware binary itself could exclude a significant part of the problem = set around updating embedded IOT operating systems that would not = technically be classified as FW.

I think SUIT is good and = broad.


-Chris


On Oct 1, 2017, at 3:20 AM, Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr> wrote:

Hi Hannes,

thanks for the update. Reads well in my = opinion. 
A couple of comments = below:

On Fri, Sep 29, 2017 at 1:00 PM, Hannes Tschofenig = <hannes.tschofenig@gmx.net> wrote:


Firmware Updating Description (FUD)
[Alternative proposal: SUIT (Software Updates for Internet of = Things).]


To no surprise, I really like SUIT, but if the WG focuses = only on firmware and excludes other types of software updates, we should = probably keep that name for another working group ;)

On the other hand, FUD = is still a problematic name. How about an alternative such as:

FiDeL : Firmware = Description for Low-end IoT devices


out of scope are
software update solutions that aim to take the features of scripting
languages, such as JavaScript variants like JerryScript, into = account.

FYI JerryScript is fully compliant with = ECMA5.1, hence not really a "variant".
Here, I = don't think we need to be that precise anyway to get the message = across.
How about rephrasing with something = like:

"Software = update solutions that target updating software other than the firmware = binary (e.g. updating scripts) are out of scope".
Cheers

Emmanuel
 
_______________________________________________
Fud = mailing list
Fud@ietf.org
https://www.ietf.org/mailman/listinfo/fud

= --Apple-Mail=_FD9C0A42-D6BB-431F-B989-C196AAC3BFC8-- From nobody Tue Oct 3 06:43:11 2017 Return-Path: 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 B3DEE1345E3 for ; Tue, 3 Oct 2017 06:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 UwDu179t1BY6 for ; Tue, 3 Oct 2017 06:43:08 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E784913243A for ; Tue, 3 Oct 2017 06:43:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 09CAC300563 for ; Tue, 3 Oct 2017 09:43:06 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id lWtcO6OSWWdS for ; Tue, 3 Oct 2017 09:43:04 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 6160B300558 for ; Tue, 3 Oct 2017 09:43:04 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 3 Oct 2017 09:43:03 -0400 References: To: "Fud@ietf.org" In-Reply-To: Message-Id: <578DD8B8-E786-4913-AE6A-65FFA29019AD@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Fud] Editorial Charter Update X-BeenThere: fud@ietf.org 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: Tue, 03 Oct 2017 13:43:10 -0000 Here is an update to the charter text based on the comments. Note that the WG name is still FUD. Any name change will be handled by = the IESG. Russ =3D =3D =3D =3D =3D =3D =3D Firmware Updating Description (FUD) [Alternative proposal: SUIT (Software Updates for Internet of Things)] Vulnerabilities in Internet of Things (IoT) devices have raised the need for a secure firmware update mechanism that is also suitable for constrained devices. Security experts, researchers, and regulators recommend that all IoT devices be equipped with such a mechanism. While there are many proprietary firmware update mechanisms in use today, = there is a lack of a modern interoperable approach of securely updating the software in IoT devices. A firmware update solution consists of several components, including: * A mechanism to transport firmware images to IoT devices. * A manifest that provides meta-data about the firmware image (such as a firmware package identifier, the hardware the package needs to run, and dependencies on other firmware packages), as well as cryptographic information for protecting the firmware image in an end-to-end fashion. * The firmware image itself. RFC 4108 provides a manifest format that uses the Cryptographic Message Syntax (CMS) to protect firmware packages. More than ten years have passed since the publication of RFC 4108, and greater experience with IoT deployments has lead to additional functionality, requiring the work done with RFC 4108 to be revisited. The purpose of this group is to produce a second version of RFC 4108 that reflects the current best practices. This group will focus on defining a firmware update solution for Class 1 devices, as defined in RFC 7228, that is -- IoT devices with ~10 KiB RAM and ~100 KiB flash. This group will not define any transport mechanisms. In June of 2016 the Internet Architecture Board organized a workshop on 'Internet of Things (IoT) Software Update (IOTSU)', which took place at Trinity College in Dublin, Ireland. The main goal of the workshop was to foster a discussion on requirements, challenges, and solutions for bringing software and firmware updates to IoT devices. This workshop also made clear that there is a lack of regulatory requirements, which contributes to challenges associated with misaligned incentives. It is nevertheless seen as important to create standard building blocks that help interested parties implement and deploy a solid firmware update mechanism. In particular this group aims to publish three documents, namely: * An IoT firmware update architecture that includes a description of the involved entities, security threats, and assumptions. * The manifest format. * A revision to RFC 4108 that reflects the current best practices. This group will use draft-moran-fud-architecture as a starting point for discussion of the "Architecture" document. This group will use draft-moran-fud-manifest as a starting point for discussion of the "Manifest Format" specification. This group does not aim to create a standard for a generic software update mechanism for use by rich operating systems, like Linux, but instead this group will focus on software development practices in the embedded industry. "Software update solutions that target updating software other than the firmware binary (e.g. updating scripts) are also out of scope. This group will aim to develop a close relationship with silicon vendors and OEMs that develop IoT operating systems. Milestones: Dec 2017 Submit RFC 4108bis document as WG item. Dec 2017 Submit "Architecture" document as WG item. Dec 2017 Submit "Manifest Format" specification as WG item. Jul 2018 Submit "Architecture" to the IESG for publication as an Informational RFC. Nov 2018 Submit RFC 4108bis document to the IESG for publication as a Proposed Standard. Nov 2018 Submit "Manifest Format" to the IESG for publication as a Proposed Standard. Additional calendar items: Mar 2018 Release initial version of the manifest creation tools as open source. Apr 2018 Release first version of manifest test tools as open source. Jun 2018 Release first IoT OS implementation of firmware update mechanisms as open source. From nobody Wed Oct 4 06:40:14 2017 Return-Path: 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 71408134218 for ; Wed, 4 Oct 2017 06:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.909 X-Spam-Level: X-Spam-Status: No, score=-2.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com 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 MUg3zxNgwBI1 for ; Wed, 4 Oct 2017 06:40:05 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0059.outbound.protection.outlook.com [104.47.0.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CF201326DF for ; Wed, 4 Oct 2017 06:40:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8vumqmM7VJ3RgAkCIjkGtPIZIs4DpaOYX24WoPujg8k=; b=aiERWEJ1R6m4WLvw5cTGZlVY8GmEmclxZ7POjD8M/G/zYs8MkLteSEAfReT3/WWYeSo7K6urse6zAIhO8P2oa+RPjguA49O+pnNacVOoL+sSCNUAd3egGzEOmPKVauG3PfXnBmHuZ5eyw0pBENQZDpu6NJ5ZlZL6jPsoBnM4MUo= Received: from DB5PR08MB0615.eurprd08.prod.outlook.com (10.169.32.149) by DB5PR08MB0616.eurprd08.prod.outlook.com (10.169.32.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Wed, 4 Oct 2017 13:39:57 +0000 Received: from DB5PR08MB0615.eurprd08.prod.outlook.com ([fe80::5c03:d255:c707:556e]) by DB5PR08MB0615.eurprd08.prod.outlook.com ([fe80::5c03:d255:c707:556e%14]) with mapi id 15.20.0077.018; Wed, 4 Oct 2017 13:39:57 +0000 From: Brendan Moran To: "Smith, Ned" CC: "Fud@ietf.org" Thread-Topic: [Fud] A few questions / observations Thread-Index: AQHTLjdsLe1oeSwl+Em8FCdFITDsKqLHtvcAgAA0MwCAC+TagA== Date: Wed, 4 Oct 2017 13:39:57 +0000 Message-ID: References: <2BF4654C-4260-4C7C-8DD5-CF892628711B@arm.com> <88B5ACDC-AEB9-4611-B3D5-8A3C720E2795@intel.com> In-Reply-To: <88B5ACDC-AEB9-4611-B3D5-8A3C720E2795@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brendan.Moran@arm.com; x-originating-ip: [217.140.96.140] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR08MB0616; 6:Xk4R5uVy4ZGA1Cf7y4VnxZi8C50BoufdhWftJpMMTWGnQ0Gcw/39AKluBVLXRRH9hj/WS40+Yba5TmsbLej1aQIPFi7JcCGwHygpR1NiSIdLj4vXre63fKiJGpPsAfolcomO1DJ6VBO7bnosjXpf8MWzA31B9NxtKipquliIzsa7FS2PzlxhyrmYm418NpQkGSBDb7rwoWO4+wnEW8lsvu+gVR/brhxH6plIbigYqzIhCdjPbapEZkf4KX4OO2Dp9SJEgsDKj3zAktYe2fCBQvenB+DzRPty51Gdcls1t7HliAuTvotUW17WEGThPG9xttOzSGjDgfejq5XOm5ho3Q==; 5:MvNxPyuae+ulkHg7GRfoZqqC2t7HECQUxlTgkS/6yxPLxxzVwjf6aYzzRz78aLGto7v2cVU8MGihDJRZiug35YjKrPmvasDFuXAadfiFJ7rWG8tOyNNi8/6XPta4VpiZwLD5Wy9vjn39L5EXwfhXbQ==; 24:wEvDh3DcYcuOtQVWd2jvWpt9BHFMT5vbWKjjShnaGEIDbNNCGO0MpgakA0APVOMezMoif3AHE31g5QrOaLAgho/+O8NdGAwRtA0a+ehYVSk=; 7:PKQIlnZUPmv9kKdrkjb/OfvMNJFuDMulBzeLNJ60D+kQvsbZxun9EY2cLEjqyaHrvcp8y3izahBMK7YTn1ICAC1aUZVun9ampsOhIu0OCo7R6OaLZVNoVWOgqloIMSlHgQLDlNasOhdUbXdajqLDqoE+bfJcZN7XYULkWspf5C+XSU24i2ayjiv209lPEkENEOWu00/5bgVsOl3SKwaJ2TWkgZGxpx+bYCgpIGdKvmQ= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 63a4bd6a-01a5-4e01-aa7a-08d50b2d6741 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DB5PR08MB0616; x-ms-traffictypediagnostic: DB5PR08MB0616: x-exchange-antispam-report-test: UriScan:(190756311086443)(180628864354917)(192374486261705)(131327999870524)(228905959029699); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB5PR08MB0616; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB5PR08MB0616; x-forefront-prvs: 0450A714CB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(24454002)(199003)(40434004)(51444003)(377454003)(189002)(5890100001)(99286003)(6512007)(53936002)(5250100002)(236005)(54896002)(6916009)(6306002)(33656002)(2950100002)(6246003)(2900100001)(81156014)(81166006)(66066001)(4326008)(83716003)(8676002)(57306001)(36756003)(8936002)(76176999)(101416001)(50986999)(6436002)(7736002)(105586002)(106356001)(6486002)(5660300001)(53546010)(229853002)(86362001)(72206003)(25786009)(606006)(6506006)(2906002)(316002)(97736004)(3660700001)(6116002)(478600001)(966005)(68736007)(3280700002)(14454004)(82746002)(189998001)(50226002)(102836003)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR08MB0616; H:DB5PR08MB0615.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_F0841595E7034AFDA5574A02E21AD5EDarmcom_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2017 13:39:57.5333 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR08MB0616 Archived-At: Subject: Re: [Fud] A few questions / observations X-BeenThere: fud@ietf.org 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: Wed, 04 Oct 2017 13:40:09 -0000 --_000_F0841595E7034AFDA5574A02E21AD5EDarmcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTmVkLA0KDQo9PT09PT09PT09PT0NCkNPU0UNCg0KSSB0aGluayB0aGF0IENPU0UgY291bGQg YmUgdmVyeSBiZW5lZmljaWFsIGluIGVudmlyb25tZW50cyB3aGVyZSBhIGdlbmVyaWMgQ0JPUiBw YXJzZXIgaXMgYXZhaWxhYmxlIGFuZCBhIGdlbmVyaWMgQVNOLjEgREVSIHBhcnNlciBpcyBub3Qu IENCT1IgaGFzIGEgbWlub3IgY29tcGFjdG5lc3MgaW1wcm92ZW1lbnQgZm9yIGJhc2ljLCB1bi10 YWdnZWQgdHlwZXMuIEkgZXhwZWN0IENPU0UgYWRvcHRpb24gdG8gaW5jcmVhc2Ugb3ZlciB0aGUg bG9uZyB0ZXJtLCBiYXJyaW5nIHNvbWUgdW5leHBlY3RlZCBwcm9ibGVtIHdpdGggdGhlIGVuY29k aW5nLiBIU01zIGFyZSBhIG1vb3QgcG9pbnQsIHNpbmNlIEnigJltIG5vdCBhd2FyZSBvZiBhbnkg c3VwcG9ydCBmb3IgZWl0aGVyIENNUyBvciBDT1NFIGRpcmVjdGx5IG9uIGFuIEhTTS4NCg0KSSBk byBoYXZlIHNvbWUgY29uY2VybnMgYWJvdXQgdGhlIHVzZSBvZiBDQk9SIG1hbmlmZXN0cyB3aXRo IENPU0Ugc2lnbmF0dXJlcyBmb3IgZmlybXdhcmUgdXBkYXRlcy4NCg0KMS4gQXZhaWxhYmlsaXR5 IG9uIG1pY3JvY29udHJvbGxlcnMNClRoZSBwcmltYXJ5IHRhcmdldCBvZiBGVUQvU1VJVCBpcyBt aWNyb2NvbnRyb2xsZXJzLiBFYWNoIG9mIE9wZW5TU0wsIG1iZWRUTFMsIHRpbnlEVExTIGNvbnRh aW4gYSBYLjUwOSBwYXJzZXIsIHdoaWNoIGNvbnRhaW5zIGV2ZXJ5dGhpbmcgdGhhdCBpcyBuZWVk ZWQgZm9yIHBhcnNpbmcgYSBERVItZW5jb2RlZCBtYW5pZmVzdOKAlE4uQi4gYSBzY2hlbWEgaXMg c3RpbGwgbmVlZGVkIGluIGVhY2ggY2FzZS4gSW4gZmFjdCwgSSB3b3VsZCBiZSBzdXJwcmlzZWQg aWYgdGhlcmUgd2VyZSBhIFRMUyBsaWJyYXJ5IGF2YWlsYWJsZSB0aGF0IGRvZXNu4oCZdCBoYXZl IGFuIFguNTA5IHBhcnNlci4gVGhhdCBzdWdnZXN0cyB0byBtZSB0aGF0IERFUiBwYXJzZXJzIGFy ZSBlZmZlY3RpdmVseSB1YmlxdWl0b3VzIGFuZCB0aGF0IG9uZSBpcyBhbHJlYWR5IHByZXNlbnQg b24gZXZlcnkgZGV2aWNlIHRoYXQgaXMgdGFyZ2V0ZWQgYnkgRlVELCBzaW5jZSBpdCBpcyB1bmxp a2VseSB0aGF0IHRoZXJlIHdvdWxkIGJlIGEgRlVEIHRhcmdldCB3aXRob3V0IGEgVExTIGxpYnJh cnkuIEl0IG1heSBiZSBpbiB0aGUgZnV0dXJlIHRoYXQgQ0JPUiBwYXJzZXJzIGFuZCBDT1NFIGNl cnRpZmljYXRlcyBhbHNvIGJlY29tZSB1YmlxdWl0b3VzLCBidXQgaXQgaXMgdG9vIGVhcmx5IHRv IHRlbGwuDQoNCjIuIFNjaGVtYXMNCkluIEFTTi4xLCB0aGUgbWVhbmluZyBvZiBhIGZpZWxkIGlz IGRldGVybWluZWQgYnkgaXRzIHBvc2l0aW9uIGluIHRoZSBzY2hlbWEsIHNvIHRoZSBzZW1hbnRp Y3Mgb2YgYW55IGZpZWxkIGFyZSBpbXBsaWNpdC4gQ0JPUiBleHBsaWNpdGx5IHN0YXRlcyB0aGF0 IG5vIHNjaGVtYSBpcyBuZWVkZWQsIGNpdGluZzoNCg0KPiBUaGlzIHdvcmtzIG11Y2ggYmV0dGVy IGluIGEgd29ybGQgd2hlcmUgYm90aCBlbmRzIG9mIGEgY29tbXVuaWNhdGlvbiByZWxhdGlvbnNo aXAgbWF5IGJlIGV2b2x2aW5nIGF0IGhpZ2ggc3BlZWQuDQoNCldoaWxlIEkgZG8gYW50aWNpcGF0 ZSB0aGF0IHRoaXMgaXMgdXNlZnVsIGluIG1hbnkgY2lyY3Vtc3RhbmNlcywgSeKAmW0gbm90IGNv bnZpbmNlZCB0aGF0IGl0IGlzIGFjY3VyYXRlIGluIEZpcm13YXJlIFVwZGF0ZS4gVGhlIGxhY2sg b2Ygc2NoZW1hIGNhdXNlcyBzZXZlcmFsIHByb2JsZW1zOg0KYSkgSW4gb3JkZXIgdG8gaWRlbnRp ZnkgYSBwYXJ0aWN1bGFyIGZpZWxkIGluIGEgZ3JvdXAgYXQgdGhlIHNhbWUgbmVzdGluZyBsZXZl bCwgQ0JPUiB1c2VzIG1hcHMuIE1hcHMgcmVxdWlyZSBhbiBhZGRpdGlvbmFsIHR5cGUgcGVyIGZp ZWxkLiBUaGlzIGVsaW1pbmF0ZXMgYW55IHNhdmluZ3MgaW4gc2l6ZSB0aGF0IGFyZSBncmFudGVk IGJ5IHRoZSBjb21wYWN0bmVzcyBvZiBDQk9S4oCZcyBiYXNpYyB0eXBlIGVuY29kaW5nLg0KYikg SWYgYSBwYXJ0aWN1bGFyIG1hcCBpcyBwYXJzZWQgYW5kIHRoZW4gcmUtZW5jb2RlZCwgaXQgbWF5 IG5vdCByZS1lbmNvZGUgdGhlIHNhbWUgd2F5IGFzIGl0IHdhcyBvcmlnaW5hbGx5IGVuY29kZWQu IFRoaXMgY2F1c2VzIHByb2JsZW1zIGZyb20gYSBzaWduYXR1cmUgdmVyaWZpY2F0aW9uIHBlcnNw ZWN0aXZlLCBhbmQgaXQgaXMgdGhlIHJlYXNvbiB0aGF0IEFTTi4xIERFUiB3YXMgZGVyaXZlZCBm cm9tIEFTTi4xIEJFUi4NCmMpIEV2ZW4gd2l0aG91dCBhIGZvcm1hbCBzY2hlbWEsIGFuIGluZm9y bWFsIHNjaGVtYSBtdXN0IGJlIGNyZWF0ZWQuIFdoZXRoZXIgdGhpcyBpcyBleGlzdGVuY2UgY2hl Y2tzIG9yIG5vbi1leGlzdGVuY2UgY2hlY2tzLCBpdCBsZWF2ZXMgdGhlIHNjaGVtYSB1cCB0byBl YWNoIGltcGxlbWVudG9yLCB3aGljaCBjYW4gYmUgZXJyb3ItcHJvbmUuIEEgZm9ybWFsIHNjaGVt YSBpcyBhIG11Y2ggbW9yZSByb2J1c3QgZXJyb3IgY2hlY2tpbmcgbWVjaGFuaXNtLCBwYXJ0aWN1 bGFybHkgaWYgaXQgaXMgcG9zc2libGUgdG8gZ2VuZXJhdGUgdGhlIHBhcnNlciBkaXJlY3RseSBm cm9tIHRoZSBzY2hlbWEuDQpkKSBEZXZpY2VzIG1heSBzdXBwb3J0IHRoaXMgZm9ybWF0IGZvciBt b3JlIHRoYW4gMjAgeWVhcnMsIHNvIGEgcmFwaWRseSBjaGFuZ2luZyBlbnZpcm9ubWVudCBpcyBu b3QgaGVscGZ1bC4gQSBzY2hlbWEgdGhhdCBjYW4gYmUgdGVzdGVkIGFnYWluc3QgaGVscHMgd2hl biBmdXR1cmUgaW1wbGVtZW50YXRpb25zIG5lZWQgdG8gYmUgdGVzdGVkIGZvciBiYWNrd2FyZHMg Y29tcGF0aWJpbGl0eS4NCg0KVGhlcmVmb3JlLCBpZiBDT1NFIHdlcmUgdG8gYmUgdXNlZCwgSSBi ZWxpZXZlIHRoYXQgd2Ugc2hvdWxkIHVzZSBhIHNjaGVtYSB3aXRoIHRoZSBDQk9SIG1hbmlmZXN0 LiBQZXJoYXBzLCBpZiB0aGF0IHdlcmUgdGhlIGNhc2UsIHRoZXJlIG1pZ2h0IGJlIGEgRE1MIHRo YXQgaXMgYm90aCBkZXNjcmlwdGl2ZSBlbm91Z2ggdG8gbGF5b3V0IGEgQ0JPUiBtYW5pZmVzdCwg YW5kIGhhcyBlbm91Z2ggdG9vbGluZyB0byBnZW5lcmF0ZSBhIHNwZWNpYWxpc2VkIEMgQ0JPUiBw YXJzZXIgZXhwbGljaXRseSBmb3IgdGhlIG1hbmlmZXN0Lg0KDQozLiBNYXR1cml0eQ0KQ01TIGhh cyBiZWVuIGluIHVzZSBzaW5jZSBhdCBsZWFzdCAxOTk4IChhcyBQS0NTNyBiZWZvcmUgdGhhdCkg YW5kIGhhcyBicm9hZCBzdXBwb3J0IGFuZCB2YWxpZGF0aW9uLiBUaGlzIGhhcyBwcm92aWRlZCB0 aW1lIGZvciBwcm9ibGVtcyBzdWNoIGFzIHRob3NlIGRldGFpbGVkIGluIFJGQzYyMTEgdG8gYmUg aWRlbnRpZmllZCBhbmQgY29ycmVjdGVkLiBDT1NFIHdhcyBwcm9wb3NlZCBpbiAyMDE1IGFuZCBz dGFuZGFyZGlzZWQgaW4gSnVseSAyMDE3LiBDTVMgaXMgYSBmYXIgbW9yZSBtYXR1cmUgc3RhbmRh cmQgdGhhbiBDT1NFLiBUaGlzIGlzIG5vdCB0byBzYXkgdGhhdCBDT1NFIGRvZXNu4oCZdCBoYXZl IGFkdmFudGFnZXMgb3ZlciBDTVMuIFNpbXBseSB0aGF0IENNUyBoYXMgYW4gZW5vcm1vdXMgbnVt YmVyIG9mIGRlcGxveWVkIGluc3RhbmNlcyBhbmQgYW4gZW5vcm1vdXMgcXVhbnRpdHkgb2YgdGVz dGluZyBiZWhpbmQgaXQuDQoNClVsdGltYXRlbHksIEkgdGhpbmsgdGhhdCBDQk9SL0NPU0Ugd2ls bCBiZWNvbWUgdmVyeSB1c2VmdWwgZm9yIHRoaXMgc29ydCBvZiB1c2UtY2FzZS4gQXQgdGhlIG1v bWVudCwgaG93ZXZlciwgSSB0aGluayB0aGF0IEFTTi4xIERFUi9DTVMgaXMgdGhlIHByYWdtYXRp YyBjaG9pY2UsIGR1ZSB0byBhdmFpbGFiaWxpdHkgb24gTUNVcywgYXZhaWxhYmlsaXR5IG9mIGEg RE1ML3NjaGVtYSBsYW5ndWFnZSB3aXRoIHJlbGV2YW50IHRvb2xpbmcsIGFuZCB0aGUgbWF0dXJp dHkgb2YgdGhlIGZvcm1hdC4NCg0KPT09PT09PT09PT09DQoNCkhTTXM6DQoNCk9uIHRoZSByb2xl IG9mIEhTTXMgaW4gZmlybXdhcmUgdXBkYXRlOiBQbGVhc2UgY29uc2lkZXIgdGhlIHVzZSBvZiBz bWFydCBjYXJkcywgaGFyZHdhcmUgdG9rZW5zLCBhbmQgb3RoZXIgc21hcnQtY2FyZCBlcXVpdmFs ZW50cy4gVGhpcyBjbGFzcyBvZiBkZXZpY2UgaXMgYm90aCBlZmZlY3RpdmVseSBhbiBIU00gYW5k IGludGVuZGVkIGFzIGEgbWVzc2FnZSBwcm9jZXNzb3IuDQoNCk9uZSBvZiB0aGUgdGhyZWF0cyB0 byBmaXJtd2FyZSB1cGRhdGUgSSBoYXZlIGNvbnNpZGVyZWQgaXMgdGhlIGV4cG9zdXJlIG9mIGEg ZGV2ZWxvcGVyIHByaXZhdGUga2V5LCBlaXRoZXIgdmlhIGV4ZmlsdHJhdGlvbiBvZiB0aGUga2V5 IGl0c2VsZiwgb3IgdGhyb3VnaCByZW1vdGUgYWNjZXNzIHRvIHRoZSBkZXZlbG9wZXIgbWFjaGlu ZS4gU2hvdWxkIHRoaXMgaGFwcGVuLCB0aGUgZnVsbCBmbGVldCBvZiBkZXZpY2VzIGZvciB3aGlj aCB0aGUgZGV2ZWxvcGVyIGhhcyBhY2Nlc3MgcmlnaHRzIGNvdWxkIGJlIGNvbXByb21pc2VkLiBH aXZlbiB0aGF0IHNtYXJ0IGNhcmRzIGFuZCBoYXJkd2FyZSB0b2tlbnMgYXJlIGF2YWlsYWJsZSwg bG93IGNvc3QsIGFuZCBtaXRpZ2F0ZSB0aGlzIHRocmVhdCBieSBob3N0aW5nIHByaXZhdGUga2V5 cywgaXQgd291bGQgc2VlbSBwcnVkZW50IHRvIHVzZSB0aGVtIGZvciBsYXJnZSBzY2FsZSBwcm9k dWN0aW9uIGVudmlyb25tZW50cy4NCg0KVGhpcyBpcyBub3QgdG8gc2F5IHRoYXQgdGhlIHVzZSBv ZiBIU01zIHNob3VsZCBiZSBtYW5kYXRlZCwgYnV0IHRoYXQgYW55IHNvbHV0aW9uIHNob3VsZCBt YWtlIGl0IGVhc3kgdG8gdXNlIHRoZW0uDQoNCg0KVGhhbmtzLA0KDQpCcmVuZGFuDQpPbiAyNyBT ZXAgMjAxNywgYXQgMDE6MDEsIFNtaXRoLCBOZWQgPG5lZC5zbWl0aEBpbnRlbC5jb208bWFpbHRv Om5lZC5zbWl0aEBpbnRlbC5jb20+PiB3cm90ZToNCg0KU2VlIGFkZGl0aW9uYWwgY29tbWVudHMg aW5saW5lIGJlbG93Lg0KLU5lZA0KDQpGcm9tOiBCcmVuZGFuIE1vcmFuIDxCcmVuZGFuLk1vcmFu QGFybS5jb208bWFpbHRvOkJyZW5kYW4uTW9yYW5AYXJtLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBT ZXB0ZW1iZXIgMjYsIDIwMTcgYXQgMTo1NCBQTQ0KVG86ICJTbWl0aCwgTmVkIiA8bmVkLnNtaXRo QGludGVsLmNvbTxtYWlsdG86bmVkLnNtaXRoQGludGVsLmNvbT4+DQpDYzogIkZ1ZEBpZXRmLm9y ZzxtYWlsdG86RnVkQGlldGYub3JnPiIgPEZ1ZEBpZXRmLm9yZzxtYWlsdG86RnVkQGlldGYub3Jn Pj4NClN1YmplY3Q6IFJlOiBbRnVkXSBBIGZldyBxdWVzdGlvbnMgLyBvYnNlcnZhdGlvbnMNCg0K SGkgTmVkLA0KSeKAmXZlIHBsYWNlZCBteSBjb21tZW50cyBpbmxpbmUuDQoNClRoYW5rcyBmb3Ig eW91ciBmZWVkYmFjayENCg0KQmVzdCBSZWdhcmRzLA0KQnJlbmRhbg0KDQoNCk9uIDE1IFNlcCAy MDE3LCBhdCAxNjoyOSwgU21pdGgsIE5lZCA8bmVkLnNtaXRoQGludGVsLmNvbTxtYWlsdG86bmVk LnNtaXRoQGludGVsLmNvbT4+IHdyb3RlOg0KW3N0dWZmIGRlbGV0ZWRdDQrigKIgICAgICAgICBX aHkgd2FzIEFTTi4xIHNlbGVjdGVkIGFzIHRoZSBlbmNvZGluZyBmb3JtYXQ/IChXaHkgbm90IENP U0U/KQ0KDQpBU04uMSB3YXMgdXNlZCBmb3IgYSBmZXcgcmVhc29ucy4NCg0KICAxLiAgSXQgaXMg dGhlIGRlZmF1bHQgZm9ybWF0IGZvciBjZXJ0aWZpY2F0ZXMuIE1vc3QgdG9vbHMgdXNlIERFUiBy YXRoZXIgdGhhbiBDT1NFIGZvciBwYWNraW5nIGNlcnRpZmljYXRlcywgc28gdGhpcyByZWR1Y2Vz IHRoZSBudW1iZXIgb2YgcGFyc2VycyBpbiB0aGUgdGFyZ2V0LiBXaGVyZSBpbnRlcndvcmsgd2l0 aCBIU01zIGlzIGludm9sdmVkLCB1c2luZyBhIGZvcm1hdCB0aGUgSFNNIHN1cHBvcnRzIGlzIGJl bmVmaWNpYWwuDQoNCltubXNdIEhTTXMgYXJlIGEgY29tcHV0aW5nIGVudmlyb25tZW50IHRoYXQg aXMgY29uc3RyYWluZWQgdG8gb3BlcmF0aW9ucyBpbnZvbHZpbmcgbW9zdGx5IGNyeXB0b2dyYXBo aWMgYW5kIGtleSBleGNoYW5nZSBvcGVyYXRpb25zLiBZb3VyIG9ic2VydmF0aW9uIGlzIHRoYXQg QVNOLjEgaXMgdGhlIGRhdGEgbW9kZWwgbGFuZ3VhZ2Ugb2YgY2hvaWNlIGJ5IHRoZSBIU00gY29t bXVuaXR5LiBJIGFncmVlIHRoYXQgaXMgdGhlIGNvcnJlY3QgY2hvaWNlIGZvciB0aGF0IGNvbnN0 cmFpbmVkIGVudmlyb25tZW50LiBIb3dldmVyLCBpdCBpcyBhbHNvIHRoZSBjYXNlIHRoYXQgdGhl cmUgYXJlIG90aGVyIGVudmlyb25tZW50cyB0aGF0IGhhdmUgY2hvc2VuIGRpZmZlcmVudCBkYXRh IG1vZGVsIGxhbmd1YWdlcyBhbmQgb3BlcmF0ZSBpbiBhIGNvbnN0cmFpbmVkIGVudmlyb25tZW50 LiBDT1NFLCBKU09OIGFuZCBYTUwgYXJlIGNvbW1vbmx5IGF2YWlsYWJsZSBwYXJzZXJzIGluIHRo ZXNlIG90aGVyIGVudmlyb25tZW50cy4gVGhlIGxvZ2ljIHRoYXQgYXJndWVzIGZvciBwcm9wYWdh dGlvbiBvZiBBU04uMSBiZWNhdXNlIHRoZSBIU00g4oCcY29uc3RyYWluZWQgZW52aXJvbm1lbnQg YWxyZWFkeSBzdXBwb3J0cyBpdCBhbmQgdGhlcmVmb3JlIGF2b2lkcyDigJhibG9hdOKAmSBvZiBh biBhZGRpdGlvbmFsIHBhcnNlcuKAnSBjYW4gYmUgdXNlZCB0byBhcmd1ZSB0aGUgb3RoZXIgc2lk ZSBhcyB3ZWxsLiBTaW5jZSB0aGUgY29uc3RyYWluZWQgZGV2aWNlIGFscmVhZHkgc3VwcG9ydHMg YW4gYWx0ZXJuYXRpdmUgKGUuZy4gQ09TRSwgSlNPTiwgWE1M4oCmKSBhbmQgdGhlIGRlcGVuZGVu Y2Ugb24gQVNOLjEgcmVwcmVzZW50cyBhZGRpdGlvbmFsIG92ZXJoZWFkIHRvIHRoZSBjb25zdHJh aW5lZCBlbnZpcm9ubWVudC4gSW4gY2FzZXMgd2hlcmUgYm90aCBhbiBhcHBsaWNhdGlvbiBwcm9j ZXNzb3IgYW5kIEhTTSBlbnZpcm9ubWVudHMgZXhpc3QgaXQgbWFrZXMgc2Vuc2UgdG8gdXNlIG9u ZSBvciB0aGUgb3RoZXIgb3IgYm90aCwgYnV0IG5vdCBpbnRyb2R1Y2UgYSB0aGlyZC4gSeKAmW0g bm90IHRha2luZyBhIHN0cm9uZyBwb3NpdGlvbiBvbiBBU04uMSB2cy4gQ09TRSAob3Igc29tZSBv dGhlciBhbHRlcm5hdGl2ZSkgZXhjZXB0IHRvIG9ic2VydmUgdGhhdCBpdCBzaG91bGRu4oCZdCBi ZSB0aGUgb2JqZWN0aXZlIG9mIEZVRCB0byBhZHZvY2F0ZSBhIHBhcnRpY3VsYXIgZGF0YSBtb2Rl bCBsYW5ndWFnZSBvdmVyIGFub3RoZXIsIGJ1dCByYXRoZXIgc2hvdWxkIHRyeSB0byBhY2NvbW1v ZGF0ZSB0aGUgZGF0YSBtb2RlbCBsYW5ndWFnZSBjaG9pY2VzIG9mIHRoZSBjb25zdHJhaW5lZCBl bnZpcm9ubWVudHMgZm9yIHdoaWNoIHRoaXMgUkZDIGhvcGVzIHRvIGJlIHJlbGV2YW50LiBJdCBz aG91bGQgYmUgbm90ZWQgdGhhdCBtb3N0IGRhdGEgbW9kZWwgbGFuZ3VhZ2VzIHRoYXQgZW1icmFj ZSBzZWN1cml0eSB0eXBpY2FsbHkgbWFrZSBhY2NvbW1vZGF0aW9uIGZvciBhIHNlY3VyaXR5IERN TCBieSBlbmNhcHN1bGF0aW5nIFBLQ1MgYW5kIFguNTA5IC0gaW1wbHlpbmcgQVNOLjEvQkVSL0RF UiBzdXBwb3J0IGV4aXN0cyBzb21ld2hlcmUgaW4gdGhlIHBsYXRmb3JtLiBIb3dldmVyLCBzdXBw b3J0IGZvciBQS0NTL1guNTA5IHNob3VsZCB0cmFuc2xhdGUgdG8gZ2VuZXJhbCBhbmQgYnJvYWQg c3VwcG9ydCBmb3IgYW55dGhpbmcgQVNOLjEgYXMgdGhlIHJhbmdlIG9mIG9iamVjdHMga25vd24g dG8gUEtDUyBhbmQgWC41MDkgaXMgdHlwaWNhbGx5IHJhdGhlciBzbWFsbC4NCk15IG9waW5pb24g aXMgdGhlIGVudmlyb25tZW50IHRoYXQgZ2VuZXJhdGVzLCBkaXN0cmlidXRlcyBhbmQgaW5zdGFs bHMgc29mdHdhcmUgdXBkYXRlcyBpc27igJl0IGVudGlyZWx5IEhTTSBvciBhcHBsaWNhdGlvbiBm cmFtZXdvcmsgKGUuZy4gTFdNMk0pLiBUaGVyZWZvcmUsIGl0IGlzIHJlYXNvbmFibGUgdG8gZXhw ZWN0IG11bHRpcGxlIGVuY29kaW5ncyBtYXkgYmUgcmVxdWlyZWQuDQoNCiAgMS4gIFBDS1M3IC8g Q01TIC8gUkZDNTY1MiBhcmUgd2lkZWx5IHN1cHBvcnRlZC4gRm9yIGV4YW1wbGUsIE9wZW5TU0zi gJlzIHNtaW1lIGNvbW1hbmQgaGFuZGxlcyBDTVMgc2lnbmluZy92YWxpZGF0aW9uIGRpcmVjdGx5 LiBUaGlzIG1ha2VzIHRoZSBjdXN0b20gdG9vbGluZyByZXF1aXJlZCBzaW1wbGVyLiBUaGlzIHdp bGwgYWxzbywgaG9wZWZ1bGx5LCBpbXByb3ZlIGNvbXBhdGliaWxpdHkgd2l0aCBleGlzdGluZyBI U01zDQoNCltubXNdIEl0IGlzIGFsc28gdGhlIGNhc2UgdGhhdCBjb25zdHJhaW5lZCBlbnZpcm9u bWVudHMgbWF5IG5vdCBoYXZlIGNob3NlbiBPcGVuU1NMLCBidXQgaW5zdGVhZCByZWx5IG9uIGVt YmVkVExTLCB0aW55RFRMUyBvciBvdGhlciBsaWJyYXJ5IHRoYXQgZG9lc27igJl0IGhhdmUgdGhl IHNhbWUgZGVwZW5kZW5jeSBvbiBTTUlNRS4gQ29tcGF0aWJpbGl0eSB3aXRoIEhTTXMgaXMgaW1w b3J0YW50LCBidXQgdGhlIHF1ZXN0aW9uIGZvciBGVUQgcG90ZW50aWFsbHkgaXMgdG8gdW5kZXJz dGFuZCBob3cgbXVjaCBvZiB0aGUgUkZD4oCZcyBzb2x1dGlvbiBzaG91bGQgYmUgY29tcHV0ZWQg d2l0aGluIHRoZSBIU00gdnMuIHRoZSBob3N0IHByb2Nlc3NpbmcgZW52aXJvbm1lbnQgb3IgYW4g YXZhaWxhYmxlIFRFRS4NCg0KICAxLiAgRGlyZWN0IGNvZGUgZ2VuZXJhdGlvbi4gSW4gYSBzY2Vu YXJpbyB3aGVyZSB0aGUgcGFyc2VyIGRvZXMgbm90IGNyZWF0ZSBhIGRvY3VtZW50IG9iamVjdCBt b2RlbCwgYnV0IGV4dHJhY3RzIG9yIHZhbGlkYXRlcyBzcGVjaWZpYyBmaWVsZHMsIEFTTi4xIHBy b3ZpZGVzIGEgZ3JhbW1hciB0aGF0IG1ha2VzIGl0IHBvc3NpYmxlIHRvIGdlbmVyYXRlIGEgcGFy c2VyIHByb2dyYW1tYXRpY2FsbHkuDQoNCltubXNdIEl0IGlzIHRydWUgdGhhdCB0aGUgQVNOLjEg dG9vbHMgZWNvc3lzdGVtIGlzIG1hdHVyZS4gQVNOLjEgaGFzIGJlZW4gYXJvdW5kIGZvciBhIHdo aWxlLiBUaGF0IGhvd2V2ZXIgaGFzIG5vdCBwcmV2ZW50ZWQgdGhlIGludmVudGlvbiBhbmQgcHJv bGlmZXJhdGlvbiBvZiBhbHRlcm5hdGl2ZSBkYXRhIG1vZGVsIGxhbmd1YWdlcy4gSWYgdGhlIGFy Z3VtZW50IGlzIHRoYXQgQVNOLjEgd2lsbCBldmVudHVhbGx5IHdpbiwgd2UganVzdCBuZWVkIHRv IHdhaXQgbG9uZ2VyLCB0aGVuIEkgcmVzcGVjdGZ1bGx5IGRpc2FncmVlLiBUaGUgZWNvc3lzdGVt cyBzdXBwb3J0aW5nIGFsdGVybmF0aXZlIERNTHMgbWF5IGJlIGxlc3MgbWF0dXJlLCBidXQgdGhl eSBhcmUgZXZvbHZpbmcgcXVpY2tseS4NCg0KICAxLiAgVGhlIG1lYW5pbmcgb2Yg4oCcbGVuZ3Ro 4oCdIGZvciBjb21wb3NpdGUgdHlwZXMuIEluIERFUiwgdGhlIGxlbmd0aCBvZiBhIGZpZWxkIGlz IHVuYW1iaWd1b3VzLiBJdCBpcyBhbHdheXMgdGhlIGxlbmd0aCwgaW4gYnl0ZXMsIG9mIHRoZSBj b250YWluZWQgb2JqZWN0LiBUaGlzIGFsbG93cyBhIHBhcnNlciB0aGF0IHVuZGVyc3RhbmRzIHRo ZSBkb2N1bWVudCBiZWluZyBwYXJzZWQgdG8gc2tpcCBsYXJnZSBjaHVua3Mgb2YgYSBkZWVwbHkg bmVzdGVkIHRyZWUuIEluIENCT1IsIHRoZSDigJxsZW5ndGjigJ0gb2YgYW4gYXJyYXkgb3IgbWFw IGlzIHRoZSBudW1iZXIgb2YgZWxlbWVudHMgaXQgY29udGFpbnMuIFRoaXMgbWFrZXMgaXQgaW1w b3NzaWJsZSBmb3IgdGhlIHBhcnNlciB0byDigJxza2lw4oCdIGFueXRoaW5nLiBJdCBoYXMgdG8g cGFyc2UgdGhlIGVudGlyZSBzdHJ1Y3R1cmUuIEl0IGlzIHBvc3NpYmxlIHRvIGNpcmN1bXZlbnQg c29tZSBvZiB0aGVzZSBsaW1pdGF0aW9ucyB1c2luZyB0YWdnaW5nLCBpbiBwYXJ0aWN1bGFyIHRh ZyAyNCAoZW5jb2RlZCBDQk9SIGRhdGEgaXRlbSksIGJ1dCB0aGlzIGhhcyB0aGUgZG93bnNpZGUg b2YgYnJlYWtpbmcgdHJhbnNsYXRhYmlsaXR5IHRvIEpTT04sIHdoaWNoIGlzIGEga2V5IGFkdmFu dGFnZSBvZiBDQk9SLiBDb25zaXN0ZW50IFRMViByZXByZXNlbnRhdGlvbiBtYWtlcyBwYXJzaW5n IGluIGEgY29uc3RyYWluZWQgZW52aXJvbm1lbnQgb2ZmZXJzIGEgbm90aW9uYWwgcGVyZm9ybWFu Y2UgaW1wcm92ZW1lbnQsIGJ1dCB0aGlzIGlzIG1pbm9yIGFuZCBtYXkgbm90IHBsYXkgb3V0IGlu IHByYWN0aWNlLg0KDQpbbm1zXSBUaGUgcXVlc3Rpb24gdG8gYXNrIGlzIHdoZXRoZXIgdGhpcyBz b3J0IG9mIHBhcnNpbmcgaW5lZmZpY2llbmN5IGlzIGEgbGFyZ2VyIHBhaW4gcG9pbnQgdGhhbiBo YXZpbmcgdG8gZG8gc2VtYW50aWMgbWFwcGluZyBvZiBzdHJ1Y3R1cmVzIHRoYXQgYWxyZWFkeSBh cmUgbWVhbmluZ2Z1bCBpbiB0aGUgY29udGV4dCBvZiB0aGUgYXBwbGljYXRpb24gZW52aXJvbm1l bnQgdGhhdCBpcyBwZXJmb3JtaW5nIHRoZSB1cGRhdGUuIEluIHN1Y2ggYSBjYXNlLCBBU04uMSBt YXkgYmUgdGhlIGdyZWF0ZXIgcGFpbiBwb2ludC4NCg0KTmV2ZXIgdGhlIGxlc3MsIEkgdGhpbmsg dGhhdCBDQk9SL0NPU0Ugd291bGQgYmUgcGVyZmVjdGx5IHNlcnZpY2VhYmxlIGZvciB0aGlzIHVz ZS4gSeKAmW0gbm90IGV2ZW4gY2VydGFpbiB0aGF0IEFTTi4xIGNhbuKAmXQgYmUgdXNlZCBhcyBh IHNjaGVtYSBmb3IgQ0JPUiAoc2VlIDMgYWJvdmUpLiBUaGF0IGJlaW5nIHRoZSBjYXNlLCBJIGNh biBzZWUgYSBjYXNlIGZvciBERVIgbWFuaWZlc3RzIHdpdGggQ01TLCBhbmQgQ0JPUiBtYW5pZmVz dHMgd2l0aCBDT1NFLg0KDQogICAgICAgICAgICBbbm1zXSBHaXZlbiBDT1NFIGVuY29kZXMgWC41 MDkgYW5kIFBLQ1Mgc3RydWN0dXJlcyBpdCB3b3VsZCBzZWVtIHRoZSBkZXNpZ25lcnMgYW50aWNp cGF0ZWQgaW50ZXJvcGVyYXRpb24gd2l0aCBIU01zLCBhdCBsZWFzdCBhdCB0aGUga2V5IGFuZCBj ZXJ0aWZpY2F0ZSBsZXZlbHMgb2YgYWJzdHJhY3Rpb24uIEJ1dCBnaXZlbiBDT1NFIGRlZmluZXMg YSBjcnlwdG9ncmFwaGljIG1lc3NhZ2Ugc3ludGF4IG9mIGl0cyBvd24sIGl0IGFudGljaXBhdGVz IHJlbGV2YW5jZSBpbiBtZXNzYWdpbmcgcHJvY2Vzc29yIGVudmlyb25tZW50cy4gTXkgdW5kZXJz dGFuZGluZyBvZiBIU01zIGFyZSB0aGF0IHRoZXkgZG9u4oCZdCBhbnRpY2lwYXRlIGJlaW5nIHVz ZWQgYXMgbWVzc2FnZSBwcm9jZXNzb3JzLiBNeSBxdWVzdGlvbiBtYXkgYmUgYSBiaXQgbW9yZSBw aGlsb3NvcGhpY2FsLiBEbyB0aGUgYXV0aG9ycyBvZiB0aGUgUkZDIHJlZ2FyZCB0aGUgZXhjaGFu Z2Ugb2YgU1cgdXBkYXRlcyBhbmQgdGhlaXIgbWFuaWZlc3RzIGFzIGJlaW5nIGZ1bmRhbWVudGFs bHkgYW4gSFNNIHdvcmtsb2FkIG9yIHNvbWV0aGluZyBlbHNlOyBzdWNoIGFzIGRldmljZSBtYW5h Z2VtZW50IG9yIHBvc3NpYmx5IGEgZGlzdHJpYnV0ZWQgY29tcHV0ZT8NCg0KVGh4LA0KTmVkDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZ1ZCBt YWlsaW5nIGxpc3QNCkZ1ZEBpZXRmLm9yZzxtYWlsdG86RnVkQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9mdWQNCg0KSU1QT1JUQU5UIE5PVElDRTogVGhl IGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50 aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRv IG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZv ciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1l ZGl1bS4gVGhhbmsgeW91Lg0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhp cyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNv IGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRo ZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBv ciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3Uu DQo= --_000_F0841595E7034AFDA5574A02E21AD5EDarmcom_ Content-Type: text/html; charset="utf-8" Content-ID: <2B9D92540E10FC428E4C811080A93193@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5IaSBOZWQs PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij49PT09PT09PT09PT08L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q09TRTwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSB0aGluayB0aGF0IENP U0UgY291bGQgYmUgdmVyeSBiZW5lZmljaWFsIGluIGVudmlyb25tZW50cyB3aGVyZSBhIGdlbmVy aWMgQ0JPUiBwYXJzZXIgaXMgYXZhaWxhYmxlIGFuZCBhIGdlbmVyaWMgQVNOLjEgREVSIHBhcnNl ciBpcyBub3QuIENCT1IgaGFzIGEgbWlub3IgY29tcGFjdG5lc3MgaW1wcm92ZW1lbnQgZm9yIGJh c2ljLCB1bi10YWdnZWQgdHlwZXMuIEkgZXhwZWN0IENPU0UgYWRvcHRpb24gdG8gaW5jcmVhc2UN CiBvdmVyIHRoZSBsb25nIHRlcm0sIGJhcnJpbmcgc29tZSB1bmV4cGVjdGVkIHByb2JsZW0gd2l0 aCB0aGUgZW5jb2RpbmcuIEhTTXMgYXJlIGEgbW9vdCBwb2ludCwgc2luY2UgSeKAmW0gbm90IGF3 YXJlIG9mIGFueSBzdXBwb3J0IGZvciBlaXRoZXIgQ01TIG9yIENPU0UgZGlyZWN0bHkgb24gYW4g SFNNLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+SSBkbyBoYXZlIHNvbWUgY29uY2VybnMgYWJvdXQgdGhlIHVzZSBvZiBDQk9SIG1hbmlm ZXN0cyB3aXRoIENPU0Ugc2lnbmF0dXJlcyBmb3IgZmlybXdhcmUgdXBkYXRlcy48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjEuIEF2YWls YWJpbGl0eSBvbiBtaWNyb2NvbnRyb2xsZXJzPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZSBwcmlt YXJ5IHRhcmdldCBvZiBGVUQvU1VJVCBpcyBtaWNyb2NvbnRyb2xsZXJzLiBFYWNoIG9mJm5ic3A7 T3BlblNTTCwgbWJlZFRMUywgdGlueURUTFMgY29udGFpbiBhIFguNTA5IHBhcnNlciwgd2hpY2gg Y29udGFpbnMgZXZlcnl0aGluZyB0aGF0IGlzIG5lZWRlZCBmb3IgcGFyc2luZyBhIERFUi1lbmNv ZGVkIG1hbmlmZXN04oCUTi5CLiBhIHNjaGVtYSBpcyBzdGlsbCBuZWVkZWQgaW4gZWFjaCBjYXNl LiBJbiBmYWN0LCBJIHdvdWxkDQogYmUgc3VycHJpc2VkIGlmIHRoZXJlIHdlcmUgYSBUTFMgbGli cmFyeSBhdmFpbGFibGUgdGhhdCBkb2VzbuKAmXQgaGF2ZSBhbiBYLjUwOSBwYXJzZXIuIFRoYXQg c3VnZ2VzdHMgdG8gbWUgdGhhdCBERVIgcGFyc2VycyBhcmUgZWZmZWN0aXZlbHkgdWJpcXVpdG91 cyBhbmQgdGhhdCBvbmUgaXMgYWxyZWFkeSBwcmVzZW50IG9uIGV2ZXJ5IGRldmljZSB0aGF0IGlz IHRhcmdldGVkIGJ5IEZVRCwgc2luY2UgaXQgaXMgdW5saWtlbHkgdGhhdCB0aGVyZSB3b3VsZA0K IGJlIGEgRlVEIHRhcmdldCB3aXRob3V0IGEgVExTIGxpYnJhcnkuIEl0IG1heSBiZSBpbiB0aGUg ZnV0dXJlIHRoYXQgQ0JPUiBwYXJzZXJzIGFuZCBDT1NFIGNlcnRpZmljYXRlcyBhbHNvIGJlY29t ZSB1YmlxdWl0b3VzLCBidXQgaXQgaXMgdG9vIGVhcmx5IHRvIHRlbGwuPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4yLiBTY2hlbWFzPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPkluIEFTTi4xLCB0aGUgbWVhbmluZyBvZiBhIGZpZWxkIGlzIGRl dGVybWluZWQgYnkgaXRzIHBvc2l0aW9uIGluIHRoZSBzY2hlbWEsIHNvIHRoZSBzZW1hbnRpY3Mg b2YgYW55IGZpZWxkIGFyZSBpbXBsaWNpdC4gQ0JPUiBleHBsaWNpdGx5IHN0YXRlcyB0aGF0IG5v IHNjaGVtYSBpcyBuZWVkZWQsIGNpdGluZzo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZndDsmbmJzcDtUaGlzIHdvcmtzIG11Y2ggYmV0 dGVyIGluIGEgd29ybGQgd2hlcmUgYm90aCBlbmRzIG9mIGEgY29tbXVuaWNhdGlvbiByZWxhdGlv bnNoaXAgbWF5IGJlIGV2b2x2aW5nIGF0IGhpZ2ggc3BlZWQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5XaGlsZSBJIGRvIGFudGljaXBh dGUgdGhhdCB0aGlzIGlzIHVzZWZ1bCBpbiBtYW55IGNpcmN1bXN0YW5jZXMsIEnigJltIG5vdCBj b252aW5jZWQgdGhhdCBpdCBpcyBhY2N1cmF0ZSBpbiBGaXJtd2FyZSBVcGRhdGUuIFRoZSBsYWNr IG9mIHNjaGVtYSBjYXVzZXMgc2V2ZXJhbCBwcm9ibGVtczo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ YSkgSW4gb3JkZXIgdG8gaWRlbnRpZnkgYSBwYXJ0aWN1bGFyIGZpZWxkIGluIGEgZ3JvdXAgYXQg dGhlIHNhbWUgbmVzdGluZyBsZXZlbCwgQ0JPUiB1c2VzIG1hcHMuIE1hcHMgcmVxdWlyZSBhbiBh ZGRpdGlvbmFsIHR5cGUgcGVyIGZpZWxkLiBUaGlzIGVsaW1pbmF0ZXMgYW55IHNhdmluZ3MgaW4g c2l6ZSB0aGF0IGFyZSBncmFudGVkIGJ5IHRoZSBjb21wYWN0bmVzcyBvZiBDQk9S4oCZcyBiYXNp YyB0eXBlIGVuY29kaW5nLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5iKSBJZiBhIHBhcnRpY3VsYXIg bWFwIGlzIHBhcnNlZCBhbmQgdGhlbiByZS1lbmNvZGVkLCBpdCBtYXkgbm90IHJlLWVuY29kZSB0 aGUgc2FtZSB3YXkgYXMgaXQgd2FzIG9yaWdpbmFsbHkgZW5jb2RlZC4gVGhpcyBjYXVzZXMgcHJv YmxlbXMgZnJvbSBhIHNpZ25hdHVyZSB2ZXJpZmljYXRpb24gcGVyc3BlY3RpdmUsIGFuZCBpdCBp cyB0aGUgcmVhc29uIHRoYXQgQVNOLjEgREVSIHdhcyBkZXJpdmVkIGZyb20gQVNOLjEgQkVSLjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5jKSBFdmVuIHdpdGhvdXQgYSBmb3JtYWwgc2NoZW1hLCBhbiBp bmZvcm1hbCBzY2hlbWEgbXVzdCBiZSBjcmVhdGVkLiBXaGV0aGVyIHRoaXMgaXMgZXhpc3RlbmNl IGNoZWNrcyBvciBub24tZXhpc3RlbmNlIGNoZWNrcywgaXQgbGVhdmVzIHRoZSBzY2hlbWEgdXAg dG8gZWFjaCBpbXBsZW1lbnRvciwgd2hpY2ggY2FuIGJlIGVycm9yLXByb25lLiBBIGZvcm1hbCBz Y2hlbWEgaXMgYSBtdWNoIG1vcmUgcm9idXN0IGVycm9yIGNoZWNraW5nDQogbWVjaGFuaXNtLCBw YXJ0aWN1bGFybHkgaWYgaXQgaXMgcG9zc2libGUgdG8gZ2VuZXJhdGUgdGhlIHBhcnNlciBkaXJl Y3RseSBmcm9tIHRoZSBzY2hlbWEuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmQpIERldmljZXMgbWF5 IHN1cHBvcnQgdGhpcyBmb3JtYXQgZm9yIG1vcmUgdGhhbiAyMCB5ZWFycywgc28gYSByYXBpZGx5 IGNoYW5naW5nIGVudmlyb25tZW50IGlzIG5vdCBoZWxwZnVsLiBBIHNjaGVtYSB0aGF0IGNhbiBi ZSB0ZXN0ZWQgYWdhaW5zdCBoZWxwcyB3aGVuIGZ1dHVyZSBpbXBsZW1lbnRhdGlvbnMgbmVlZCB0 byBiZSB0ZXN0ZWQgZm9yIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5LjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlcmVmb3JlLCBpZiBD T1NFIHdlcmUgdG8gYmUgdXNlZCwgSSBiZWxpZXZlIHRoYXQgd2Ugc2hvdWxkIHVzZSBhIHNjaGVt YSB3aXRoIHRoZSBDQk9SIG1hbmlmZXN0LiBQZXJoYXBzLCBpZiB0aGF0IHdlcmUgdGhlIGNhc2Us IHRoZXJlIG1pZ2h0IGJlIGEgRE1MIHRoYXQgaXMgYm90aCBkZXNjcmlwdGl2ZSBlbm91Z2ggdG8g bGF5b3V0IGEgQ0JPUiBtYW5pZmVzdCwgYW5kIGhhcyBlbm91Z2ggdG9vbGluZyB0byBnZW5lcmF0 ZQ0KIGEgc3BlY2lhbGlzZWQgQyBDQk9SIHBhcnNlciBleHBsaWNpdGx5IGZvciB0aGUgbWFuaWZl c3QuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4zLiBNYXR1cml0eTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5DTVMgaGFzIGJlZW4gaW4gdXNl IHNpbmNlIGF0IGxlYXN0IDE5OTggKGFzIFBLQ1M3IGJlZm9yZSB0aGF0KSBhbmQgaGFzIGJyb2Fk IHN1cHBvcnQgYW5kIHZhbGlkYXRpb24uIFRoaXMgaGFzIHByb3ZpZGVkIHRpbWUgZm9yIHByb2Js ZW1zIHN1Y2ggYXMgdGhvc2UgZGV0YWlsZWQgaW4gUkZDNjIxMSB0byBiZSBpZGVudGlmaWVkIGFu ZCBjb3JyZWN0ZWQuIENPU0Ugd2FzIHByb3Bvc2VkIGluIDIwMTUgYW5kIHN0YW5kYXJkaXNlZA0K IGluIEp1bHkgMjAxNy4gQ01TIGlzIGEgZmFyIG1vcmUgbWF0dXJlIHN0YW5kYXJkIHRoYW4gQ09T RS4gVGhpcyBpcyBub3QgdG8gc2F5IHRoYXQgQ09TRSBkb2VzbuKAmXQgaGF2ZSBhZHZhbnRhZ2Vz IG92ZXIgQ01TLiBTaW1wbHkgdGhhdCBDTVMgaGFzIGFuIGVub3Jtb3VzIG51bWJlciBvZiBkZXBs b3llZCBpbnN0YW5jZXMgYW5kIGFuIGVub3Jtb3VzIHF1YW50aXR5IG9mIHRlc3RpbmcgYmVoaW5k IGl0LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+VWx0aW1hdGVseSwgSSB0aGluayB0aGF0IENCT1IvQ09TRSB3aWxsIGJlY29tZSB2ZXJ5 IHVzZWZ1bCBmb3IgdGhpcyBzb3J0IG9mIHVzZS1jYXNlLiBBdCB0aGUgbW9tZW50LCBob3dldmVy LCBJIHRoaW5rIHRoYXQgQVNOLjEgREVSL0NNUyBpcyB0aGUgcHJhZ21hdGljIGNob2ljZSwgZHVl IHRvIGF2YWlsYWJpbGl0eSBvbiBNQ1VzLCBhdmFpbGFiaWxpdHkgb2YgYSBETUwvc2NoZW1hIGxh bmd1YWdlIHdpdGggcmVsZXZhbnQNCiB0b29saW5nLCBhbmQgdGhlIG1hdHVyaXR5IG9mIHRoZSBm b3JtYXQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj49PT09PT09PT09PT08L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkhTTXM6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5PbiB0aGUgcm9sZSBvZiBIU01zIGluIGZpcm13 YXJlIHVwZGF0ZTogUGxlYXNlIGNvbnNpZGVyIHRoZSB1c2Ugb2Ygc21hcnQgY2FyZHMsIGhhcmR3 YXJlIHRva2VucywgYW5kIG90aGVyIHNtYXJ0LWNhcmQgZXF1aXZhbGVudHMuIFRoaXMgY2xhc3Mg b2YgZGV2aWNlIGlzIGJvdGggZWZmZWN0aXZlbHkgYW4gSFNNIGFuZCBpbnRlbmRlZCBhcyBhIG1l c3NhZ2UgcHJvY2Vzc29yLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+T25lIG9mIHRoZSB0aHJlYXRzIHRvIGZpcm13YXJlIHVwZGF0ZSBJ IGhhdmUgY29uc2lkZXJlZCBpcyB0aGUgZXhwb3N1cmUgb2YgYSBkZXZlbG9wZXIgcHJpdmF0ZSBr ZXksIGVpdGhlciB2aWEgZXhmaWx0cmF0aW9uIG9mIHRoZSBrZXkgaXRzZWxmLCBvciB0aHJvdWdo IHJlbW90ZSBhY2Nlc3MgdG8gdGhlIGRldmVsb3BlciBtYWNoaW5lLiBTaG91bGQgdGhpcyBoYXBw ZW4sIHRoZSBmdWxsIGZsZWV0IG9mIGRldmljZXMgZm9yDQogd2hpY2ggdGhlIGRldmVsb3BlciBo YXMgYWNjZXNzIHJpZ2h0cyBjb3VsZCBiZSBjb21wcm9taXNlZC4gR2l2ZW4gdGhhdCBzbWFydCBj YXJkcyBhbmQgaGFyZHdhcmUgdG9rZW5zIGFyZSBhdmFpbGFibGUsIGxvdyBjb3N0LCBhbmQgbWl0 aWdhdGUgdGhpcyB0aHJlYXQgYnkgaG9zdGluZyBwcml2YXRlIGtleXMsIGl0IHdvdWxkIHNlZW0g cHJ1ZGVudCB0byB1c2UgdGhlbSBmb3IgbGFyZ2Ugc2NhbGUgcHJvZHVjdGlvbiBlbnZpcm9ubWVu dHMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5UaGlzIGlzIG5vdCB0byBzYXkgdGhhdCB0aGUgdXNlIG9mIEhTTXMgc2hvdWxkIGJlIG1h bmRhdGVkLCBidXQgdGhhdCBhbnkgc29sdXRpb24gc2hvdWxkIG1ha2UgaXQgZWFzeSB0byB1c2Ug dGhlbS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGFua3MsPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5CcmVu ZGFuPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPk9uIDI3IFNlcCAyMDE3LCBhdCAwMTowMSwgU21pdGgsIE5lZCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm5lZC5zbWl0aEBpbnRlbC5jb20iIGNsYXNzPSIiPm5lZC5zbWl0aEBpbnRlbC5j b208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3 bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0i cGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEy cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBi YWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbic7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpOyIgY2xhc3M9IiI+U2VlIGFkZGl0aW9uYWwgY29tbWVudHMgaW5s aW5lIGJlbG93LjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6IENhbGlicmk7IiBjbGFzcz0iIj4tTmVkPG86cCBjbGFzcz0iIj48L286 cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyIgY2xhc3M9IiI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaTsiIGNs YXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyLXN0eWxlOiBzb2xpZCBub25lIG5vbmU7IGJvcmRlci10b3Atd2lkdGg6IDFwdDsg Ym9yZGVyLXRvcC1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMpOyBwYWRkaW5nOiAzcHQgMGluIDBp bjsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPg0K PGIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpOyIgY2xhc3M9IiI+ RnJvbTo8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmk7IiBjbGFzcz0iIj5CcmVu ZGFuIE1vcmFuICZsdDs8YSBocmVmPSJtYWlsdG86QnJlbmRhbi5Nb3JhbkBhcm0uY29tIiBzdHls ZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5C cmVuZGFuLk1vcmFuQGFybS5jb208L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPkRh dGU6PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5U dWVzZGF5LCBTZXB0ZW1iZXIgMjYsIDIwMTcgYXQgMTo1NCBQTTxiciBjbGFzcz0iIj4NCjxiIGNs YXNzPSIiPlRvOjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48L2I+JnF1b3Q7U21pdGgsIE5lZCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5lZC5zbWl0 aEBpbnRlbC5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVy bGluZTsiIGNsYXNzPSIiPm5lZC5zbWl0aEBpbnRlbC5jb208L2E+Jmd0OzxiciBjbGFzcz0iIj4N CjxiIGNsYXNzPSIiPkNjOjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOkZ1ZEBpZXRmLm9yZyIgc3R5bGU9ImNv bG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+RnVkQGll dGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkZ1ZEBpZXRmLm9yZyIgc3R5bGU9 ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+RnVk QGlldGYub3JnPC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5TdWJqZWN0OjxzcGFu IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+UmU6IFtGdWRd IEEgZmV3IHF1ZXN0aW9ucyAvIG9ic2VydmF0aW9uczxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFu PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJzsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IiBjbGFzcz0i Ij4NCkhpIE5lZCw8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPg0KSeKAmXZlIHBs YWNlZCBteSBjb21tZW50cyBpbmxpbmUuPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IiBjbGFzcz0i Ij4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyIgY2xhc3M9IiI+DQpUaGFua3MgZm9y IHlvdXIgZmVlZGJhY2shPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IiBjbGFzcz0iIj4NCjxvOnAg Y2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyIgY2xhc3M9IiI+DQpCZXN0IFJlZ2FyZHMsPG86cCBj bGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbic7IiBjbGFzcz0iIj4NCkJyZW5kYW48bzpwIGNsYXNzPSIiPjwvbzpw PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJzsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0i Ij4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7IiBjbGFzcz0iIiB0eXBlPSJjaXRl Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyIgY2xhc3M9 IiI+DQpPbiAxNSBTZXAgMjAxNywgYXQgMTY6MjksIFNtaXRoLCBOZWQgJmx0OzxhIGhyZWY9Im1h aWx0bzpuZWQuc21pdGhAaW50ZWwuY29tIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNv cmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5uZWQuc21pdGhAaW50ZWwuY29tPC9hPiZndDsg d3JvdGU6PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNs YXNzPSIiPg0KW3N0dWZmIGRlbGV0ZWRdPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsiIGNsYXNz PSIiIHR5cGU9ImNpdGUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 OiAwLjVpbjsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0 OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgdGV4dC1p bmRlbnQ6IC0wLjI1aW47IGJhY2tncm91bmQtY29sb3I6IHdoaXRlOyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogU3ltYm9sOyIgY2xhc3M9IiI+ wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogN3B0OyIgY2xhc3M9IiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaTsiIGNsYXNzPSIiPldoeSB3YXMgQVNOLjEg c2VsZWN0ZWQgYXMgdGhlDQogZW5jb2RpbmcgZm9ybWF0PyAoV2h5IG5vdCBDT1NFPyk8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0i Ij48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IiBjbGFzcz0iIj4NCjxv OnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyIgY2xhc3M9IiI+DQpBU04uMSB3YXMgdXNlZCBm b3IgYSBmZXcgcmVhc29ucy48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTog MGluOyIgY2xhc3M9IiI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbic7Ij4NCkl0IGlzIHRoZSBkZWZhdWx0IGZvcm1hdCBmb3IgY2VydGlmaWNhdGVzLiBNb3N0 IHRvb2xzIHVzZSBERVIgcmF0aGVyIHRoYW4gQ09TRSBmb3IgcGFja2luZyBjZXJ0aWZpY2F0ZXMs IHNvIHRoaXMgcmVkdWNlcyB0aGUgbnVtYmVyIG9mIHBhcnNlcnMgaW4gdGhlIHRhcmdldC4gV2hl cmUgaW50ZXJ3b3JrIHdpdGggSFNNcyBpcyBpbnZvbHZlZCwgdXNpbmcgYSBmb3JtYXQgdGhlIEhT TSBzdXBwb3J0cyBpcyBiZW5lZmljaWFsLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9saT48L29sPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0IDAuNWluOyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPg0KW25tc10gSFNN cyBhcmUgYSBjb21wdXRpbmcgZW52aXJvbm1lbnQgdGhhdCBpcyBjb25zdHJhaW5lZCB0byBvcGVy YXRpb25zIGludm9sdmluZyBtb3N0bHkgY3J5cHRvZ3JhcGhpYyBhbmQga2V5IGV4Y2hhbmdlIG9w ZXJhdGlvbnMuIFlvdXIgb2JzZXJ2YXRpb24gaXMgdGhhdCBBU04uMSBpcyB0aGUgZGF0YSBtb2Rl bCBsYW5ndWFnZSBvZiBjaG9pY2UgYnkgdGhlIEhTTSBjb21tdW5pdHkuIEkgYWdyZWUgdGhhdCBp cyB0aGUgY29ycmVjdCBjaG9pY2UNCiBmb3IgdGhhdCBjb25zdHJhaW5lZCBlbnZpcm9ubWVudC4g SG93ZXZlciwgaXQgaXMgYWxzbyB0aGUgY2FzZSB0aGF0IHRoZXJlIGFyZSBvdGhlciBlbnZpcm9u bWVudHMgdGhhdCBoYXZlIGNob3NlbiBkaWZmZXJlbnQgZGF0YSBtb2RlbCBsYW5ndWFnZXMgYW5k IG9wZXJhdGUgaW4gYSBjb25zdHJhaW5lZCBlbnZpcm9ubWVudC4gQ09TRSwgSlNPTiBhbmQgWE1M IGFyZSBjb21tb25seSBhdmFpbGFibGUgcGFyc2VycyBpbiB0aGVzZSBvdGhlciBlbnZpcm9ubWVu dHMuDQogVGhlIGxvZ2ljIHRoYXQgYXJndWVzIGZvciBwcm9wYWdhdGlvbiBvZiBBU04uMSBiZWNh dXNlIHRoZSBIU00g4oCcY29uc3RyYWluZWQgZW52aXJvbm1lbnQgYWxyZWFkeSBzdXBwb3J0cyBp dCBhbmQgdGhlcmVmb3JlIGF2b2lkcyDigJhibG9hdOKAmSBvZiBhbiBhZGRpdGlvbmFsIHBhcnNl cuKAnSBjYW4gYmUgdXNlZCB0byBhcmd1ZSB0aGUgb3RoZXIgc2lkZSBhcyB3ZWxsLiBTaW5jZSB0 aGUgY29uc3RyYWluZWQgZGV2aWNlIGFscmVhZHkgc3VwcG9ydHMgYW4NCiBhbHRlcm5hdGl2ZSAo ZS5nLiBDT1NFLCBKU09OLCBYTUzigKYpIGFuZCB0aGUgZGVwZW5kZW5jZSBvbiBBU04uMSByZXBy ZXNlbnRzIGFkZGl0aW9uYWwgb3ZlcmhlYWQgdG8gdGhlIGNvbnN0cmFpbmVkIGVudmlyb25tZW50 LiBJbiBjYXNlcyB3aGVyZSBib3RoIGFuIGFwcGxpY2F0aW9uIHByb2Nlc3NvciBhbmQgSFNNIGVu dmlyb25tZW50cyBleGlzdCBpdCBtYWtlcyBzZW5zZSB0byB1c2Ugb25lIG9yIHRoZSBvdGhlciBv ciBib3RoLCBidXQgbm90IGludHJvZHVjZQ0KIGEgdGhpcmQuIEnigJltIG5vdCB0YWtpbmcgYSBz dHJvbmcgcG9zaXRpb24gb24gQVNOLjEgdnMuIENPU0UgKG9yIHNvbWUgb3RoZXIgYWx0ZXJuYXRp dmUpIGV4Y2VwdCB0byBvYnNlcnZlIHRoYXQgaXQgc2hvdWxkbuKAmXQgYmUgdGhlIG9iamVjdGl2 ZSBvZiBGVUQgdG8gYWR2b2NhdGUgYSBwYXJ0aWN1bGFyIGRhdGEgbW9kZWwgbGFuZ3VhZ2Ugb3Zl ciBhbm90aGVyLCBidXQgcmF0aGVyIHNob3VsZCB0cnkgdG8gYWNjb21tb2RhdGUgdGhlIGRhdGEg bW9kZWwNCiBsYW5ndWFnZSBjaG9pY2VzIG9mIHRoZSBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMg Zm9yIHdoaWNoIHRoaXMgUkZDIGhvcGVzIHRvIGJlIHJlbGV2YW50LiBJdCBzaG91bGQgYmUgbm90 ZWQgdGhhdCBtb3N0IGRhdGEgbW9kZWwgbGFuZ3VhZ2VzIHRoYXQgZW1icmFjZSBzZWN1cml0eSB0 eXBpY2FsbHkgbWFrZSBhY2NvbW1vZGF0aW9uIGZvciBhIHNlY3VyaXR5IERNTCBieSBlbmNhcHN1 bGF0aW5nIFBLQ1MgYW5kIFguNTA5IC0gaW1wbHlpbmcgQVNOLjEvQkVSL0RFUg0KIHN1cHBvcnQg ZXhpc3RzIHNvbWV3aGVyZSBpbiB0aGUgcGxhdGZvcm0uIEhvd2V2ZXIsIHN1cHBvcnQgZm9yIFBL Q1MvWC41MDkgc2hvdWxkIHRyYW5zbGF0ZSB0byBnZW5lcmFsIGFuZCBicm9hZCBzdXBwb3J0IGZv ciBhbnl0aGluZyBBU04uMSBhcyB0aGUgcmFuZ2Ugb2Ygb2JqZWN0cyBrbm93biB0byBQS0NTIGFu ZCBYLjUwOSBpcyB0eXBpY2FsbHkgcmF0aGVyIHNtYWxsLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQgMC41aW47IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyIgY2xhc3M9IiI+DQpNeSBv cGluaW9uIGlzIHRoZSBlbnZpcm9ubWVudCB0aGF0IGdlbmVyYXRlcywgZGlzdHJpYnV0ZXMgYW5k IGluc3RhbGxzIHNvZnR3YXJlIHVwZGF0ZXMgaXNu4oCZdCBlbnRpcmVseSBIU00gb3IgYXBwbGlj YXRpb24gZnJhbWV3b3JrIChlLmcuIExXTTJNKS4gVGhlcmVmb3JlLCBpdCBpcyByZWFzb25hYmxl IHRvIGV4cGVjdCBtdWx0aXBsZSBlbmNvZGluZ3MgbWF5IGJlIHJlcXVpcmVkLjxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9kaXY+DQo8b2wgc3RhcnQ9IjIiIHR5cGU9IjEiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOiAwaW47IiBjbGFzcz0iIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJzsiPg0KUENLUzcgLyBDTVMgLyBSRkM1NjUyIGFyZSB3aWRlbHkgc3VwcG9ydGVk LiBGb3IgZXhhbXBsZSwgT3BlblNTTOKAmXMgc21pbWUgY29tbWFuZCBoYW5kbGVzIENNUyBzaWdu aW5nL3ZhbGlkYXRpb24gZGlyZWN0bHkuIFRoaXMgbWFrZXMgdGhlIGN1c3RvbSB0b29saW5nIHJl cXVpcmVkIHNpbXBsZXIuIFRoaXMgd2lsbCBhbHNvLCBob3BlZnVsbHksIGltcHJvdmUgY29tcGF0 aWJpbGl0eSB3aXRoIGV4aXN0aW5nIEhTTXM8bzpwIGNsYXNzPSIiPjwvbzpwPjwvbGk+PC9vbD4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdCAwLjVpbjsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IiBjbGFzcz0iIj4NCltubXNdIEl0 IGlzIGFsc28gdGhlIGNhc2UgdGhhdCBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMgbWF5IG5vdCBo YXZlIGNob3NlbiBPcGVuU1NMLCBidXQgaW5zdGVhZCByZWx5IG9uIGVtYmVkVExTLCB0aW55RFRM UyBvciBvdGhlciBsaWJyYXJ5IHRoYXQgZG9lc27igJl0IGhhdmUgdGhlIHNhbWUgZGVwZW5kZW5j eSBvbiBTTUlNRS4gQ29tcGF0aWJpbGl0eSB3aXRoIEhTTXMgaXMgaW1wb3J0YW50LCBidXQgdGhl IHF1ZXN0aW9uIGZvciBGVUQgcG90ZW50aWFsbHkNCiBpcyB0byB1bmRlcnN0YW5kIGhvdyBtdWNo IG9mIHRoZSBSRkPigJlzIHNvbHV0aW9uIHNob3VsZCBiZSBjb21wdXRlZCB3aXRoaW4gdGhlIEhT TSB2cy4gdGhlIGhvc3QgcHJvY2Vzc2luZyBlbnZpcm9ubWVudCBvciBhbiBhdmFpbGFibGUgVEVF LjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8b2wgc3RhcnQ9IjMiIHR5cGU9IjEiIHN0eWxl PSJtYXJnaW4tYm90dG9tOiAwaW47IiBjbGFzcz0iIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiPg0KRGlyZWN0IGNvZGUgZ2VuZXJhdGlvbi4gSW4gYSBz Y2VuYXJpbyB3aGVyZSB0aGUgcGFyc2VyIGRvZXMgbm90IGNyZWF0ZSBhIGRvY3VtZW50IG9iamVj dCBtb2RlbCwgYnV0IGV4dHJhY3RzIG9yIHZhbGlkYXRlcyBzcGVjaWZpYyBmaWVsZHMsIEFTTi4x IHByb3ZpZGVzIGEgZ3JhbW1hciB0aGF0IG1ha2VzIGl0IHBvc3NpYmxlIHRvIGdlbmVyYXRlIGEg cGFyc2VyIHByb2dyYW1tYXRpY2FsbHkuPG86cCBjbGFzcz0iIj48L286cD48L2xpPjwvb2w+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQgMC41aW47IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyIgY2xhc3M9IiI+DQpbbm1zXSBJdCBp cyB0cnVlIHRoYXQgdGhlIEFTTi4xIHRvb2xzIGVjb3N5c3RlbSBpcyBtYXR1cmUuIEFTTi4xIGhh cyBiZWVuIGFyb3VuZCBmb3IgYSB3aGlsZS4gVGhhdCBob3dldmVyIGhhcyBub3QgcHJldmVudGVk IHRoZSBpbnZlbnRpb24gYW5kIHByb2xpZmVyYXRpb24gb2YgYWx0ZXJuYXRpdmUgZGF0YSBtb2Rl bCBsYW5ndWFnZXMuIElmIHRoZSBhcmd1bWVudCBpcyB0aGF0IEFTTi4xIHdpbGwgZXZlbnR1YWxs eSB3aW4sIHdlIGp1c3QgbmVlZA0KIHRvIHdhaXQgbG9uZ2VyLCB0aGVuIEkgcmVzcGVjdGZ1bGx5 IGRpc2FncmVlLiBUaGUgZWNvc3lzdGVtcyBzdXBwb3J0aW5nIGFsdGVybmF0aXZlIERNTHMgbWF5 IGJlIGxlc3MgbWF0dXJlLCBidXQgdGhleSBhcmUgZXZvbHZpbmcgcXVpY2tseS48bzpwIGNsYXNz PSIiPjwvbzpwPjwvZGl2Pg0KPG9sIHN0YXJ0PSI0IiB0eXBlPSIxIiBzdHlsZT0ibWFyZ2luLWJv dHRvbTogMGluOyIgY2xhc3M9IiI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbic7Ij4NClRoZSBtZWFuaW5nIG9mIOKAnGxlbmd0aOKAnSBmb3IgY29tcG9zaXRl IHR5cGVzLiBJbiBERVIsIHRoZSBsZW5ndGggb2YgYSBmaWVsZCBpcyB1bmFtYmlndW91cy4gSXQg aXMgYWx3YXlzIHRoZSBsZW5ndGgsIGluIGJ5dGVzLCBvZiB0aGUgY29udGFpbmVkIG9iamVjdC4g VGhpcyBhbGxvd3MgYSBwYXJzZXIgdGhhdCB1bmRlcnN0YW5kcyB0aGUgZG9jdW1lbnQgYmVpbmcg cGFyc2VkIHRvIHNraXAgbGFyZ2UgY2h1bmtzIG9mIGEgZGVlcGx5IG5lc3RlZCB0cmVlLg0KIElu IENCT1IsIHRoZSDigJxsZW5ndGjigJ0gb2YgYW4gYXJyYXkgb3IgbWFwIGlzIHRoZSBudW1iZXIg b2YgZWxlbWVudHMgaXQgY29udGFpbnMuIFRoaXMgbWFrZXMgaXQgaW1wb3NzaWJsZSBmb3IgdGhl IHBhcnNlciB0byDigJxza2lw4oCdIGFueXRoaW5nLiBJdCBoYXMgdG8gcGFyc2UgdGhlIGVudGly ZSBzdHJ1Y3R1cmUuIEl0IGlzIHBvc3NpYmxlIHRvIGNpcmN1bXZlbnQgc29tZSBvZiB0aGVzZSBs aW1pdGF0aW9ucyB1c2luZyB0YWdnaW5nLCBpbiBwYXJ0aWN1bGFyDQogdGFnIDI0IChlbmNvZGVk IENCT1IgZGF0YSBpdGVtKSwgYnV0IHRoaXMgaGFzIHRoZSBkb3duc2lkZSBvZiBicmVha2luZyB0 cmFuc2xhdGFiaWxpdHkgdG8gSlNPTiwgd2hpY2ggaXMgYSBrZXkgYWR2YW50YWdlIG9mIENCT1Iu IENvbnNpc3RlbnQgVExWIHJlcHJlc2VudGF0aW9uIG1ha2VzIHBhcnNpbmcgaW4gYSBjb25zdHJh aW5lZCBlbnZpcm9ubWVudCBvZmZlcnMgYSBub3Rpb25hbCBwZXJmb3JtYW5jZSBpbXByb3ZlbWVu dCwgYnV0IHRoaXMgaXMNCiBtaW5vciBhbmQgbWF5IG5vdCBwbGF5IG91dCBpbiBwcmFjdGljZS48 bzpwIGNsYXNzPSIiPjwvbzpwPjwvbGk+PC9vbD4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdCAwLjI1aW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nOyB0ZXh0LWluZGVudDogMC4yNWluOyIgY2xhc3M9IiI+DQpbbm1zXSBUaGUgcXVl c3Rpb24gdG8gYXNrIGlzIHdoZXRoZXIgdGhpcyBzb3J0IG9mIHBhcnNpbmcgaW5lZmZpY2llbmN5 IGlzIGEgbGFyZ2VyIHBhaW4gcG9pbnQgdGhhbiBoYXZpbmcgdG8gZG8gc2VtYW50aWMgbWFwcGlu ZyBvZiBzdHJ1Y3R1cmVzIHRoYXQgYWxyZWFkeSBhcmUgbWVhbmluZ2Z1bCBpbiB0aGUgY29udGV4 dCBvZiB0aGUgYXBwbGljYXRpb24gZW52aXJvbm1lbnQgdGhhdCBpcyBwZXJmb3JtaW5nIHRoZSB1 cGRhdGUuIEluIHN1Y2ggYQ0KIGNhc2UsIEFTTi4xIG1heSBiZSB0aGUgZ3JlYXRlciBwYWluIHBv aW50LjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286 cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbic7IiBjbGFzcz0iIj4NCk5ldmVyIHRoZSBsZXNzLCBJIHRoaW5rIHRoYXQgQ0JPUi9DT1NF IHdvdWxkIGJlIHBlcmZlY3RseSBzZXJ2aWNlYWJsZSBmb3IgdGhpcyB1c2UuIEnigJltIG5vdCBl dmVuIGNlcnRhaW4gdGhhdCBBU04uMSBjYW7igJl0IGJlIHVzZWQgYXMgYSBzY2hlbWEgZm9yIENC T1IgKHNlZSAzIGFib3ZlKS4gVGhhdCBiZWluZyB0aGUgY2FzZSwgSSBjYW4gc2VlIGEgY2FzZSBm b3IgREVSIG1hbmlmZXN0cyB3aXRoIENNUywgYW5kIENCT1IgbWFuaWZlc3RzIHdpdGggQ09TRS48 bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsi IGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbic7IiBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbbm1zXSBHaXZlbiBDT1NF IGVuY29kZXMgWC41MDkgYW5kIFBLQ1Mgc3RydWN0dXJlcyBpdCB3b3VsZCBzZWVtIHRoZSBkZXNp Z25lcnMgYW50aWNpcGF0ZWQgaW50ZXJvcGVyYXRpb24gd2l0aCBIU01zLCBhdCBsZWFzdCBhdCB0 aGUga2V5IGFuZCBjZXJ0aWZpY2F0ZSBsZXZlbHMgb2YgYWJzdHJhY3Rpb24uIEJ1dCBnaXZlbiBD T1NFIGRlZmluZXMgYSBjcnlwdG9ncmFwaGljIG1lc3NhZ2Ugc3ludGF4IG9mIGl0cyBvd24sIGl0 DQogYW50aWNpcGF0ZXMgcmVsZXZhbmNlIGluIG1lc3NhZ2luZyBwcm9jZXNzb3IgZW52aXJvbm1l bnRzLiBNeSB1bmRlcnN0YW5kaW5nIG9mIEhTTXMgYXJlIHRoYXQgdGhleSBkb27igJl0IGFudGlj aXBhdGUgYmVpbmcgdXNlZCBhcyBtZXNzYWdlIHByb2Nlc3NvcnMuIE15IHF1ZXN0aW9uIG1heSBi ZSBhIGJpdCBtb3JlIHBoaWxvc29waGljYWwuIERvIHRoZSBhdXRob3JzIG9mIHRoZSBSRkMgcmVn YXJkIHRoZSBleGNoYW5nZSBvZiBTVyB1cGRhdGVzIGFuZA0KIHRoZWlyIG1hbmlmZXN0cyBhcyBi ZWluZyBmdW5kYW1lbnRhbGx5IGFuIEhTTSB3b3JrbG9hZCBvciBzb21ldGhpbmcgZWxzZTsgc3Vj aCBhcyBkZXZpY2UgbWFuYWdlbWVudCBvciBwb3NzaWJseSBhIGRpc3RyaWJ1dGVkIGNvbXB1dGU/ PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nOyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaHgsPG86cCBjbGFz cz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IiBjbGFzcz0i Ij4NCk5lZDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7IiBjbGFzcz0iIiB0eXBlPSJjaXRlIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu JzsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaTsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGJhY2tncm91bmQtY29sb3I6IHdoaXRlOyBiYWNrZ3JvdW5kLXBvc2l0aW9u OiBpbml0aWFsIGluaXRpYWw7IGJhY2tncm91bmQtcmVwZWF0OiBpbml0aWFsIGluaXRpYWw7IiBj bGFzcz0iIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjog d2hpdGU7IGJhY2tncm91bmQtcG9zaXRpb246IGluaXRpYWwgaW5pdGlhbDsgYmFja2dyb3VuZC1y ZXBlYXQ6IGluaXRpYWwgaW5pdGlhbDsiIGNsYXNzPSIiPkZ1ZCBtYWlsaW5nIGxpc3Q8L3NwYW4+ PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpGdWRAaWV0Zi5vcmciIHN0eWxl PSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgY29sb3I6 IHJnYigxNDksIDc5LCAxMTQpOyBiYWNrZ3JvdW5kLWNvbG9yOiB3aGl0ZTsgYmFja2dyb3VuZC1w b3NpdGlvbjogaW5pdGlhbCBpbml0aWFsOyBiYWNrZ3JvdW5kLXJlcGVhdDogaW5pdGlhbCBpbml0 aWFsOyIgY2xhc3M9IiI+RnVkQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1z aXplOiA5cHQ7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9m dWQiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNs YXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgY29sb3I6IHJnYigxNDksIDc5LCAxMTQpOyBiYWNrZ3JvdW5kLWNvbG9yOiB3aGl0ZTsgYmFj a2dyb3VuZC1wb3NpdGlvbjogaW5pdGlhbCBpbml0aWFsOyBiYWNrZ3JvdW5kLXJlcGVhdDogaW5p dGlhbCBpbml0aWFsOyIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9mdWQ8L3NwYW4+PC9hPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0 OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRo aXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxz byBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0 aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwN CiBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5 b3UuPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8YnIgY2xhc3M9IiI+DQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhp cyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNv IGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRo ZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLA0K IG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlv dS4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_F0841595E7034AFDA5574A02E21AD5EDarmcom_-- From nobody Wed Oct 4 06:54:14 2017 Return-Path: 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 4F00F1321DC for ; Wed, 4 Oct 2017 06:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, 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 eZXT6VbdX6FS for ; Wed, 4 Oct 2017 06:54:10 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 D722A1241F3 for ; Wed, 4 Oct 2017 06:54:09 -0700 (PDT) Received: from [192.168.91.203] ([31.168.171.66]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LZiQy-1daHBq486u-00lXBL; Wed, 04 Oct 2017 15:54:07 +0200 To: Chris Rouland , fud@ietf.org References: <8E6DE4EA-ADC8-434D-9BFD-87AFE2387DCE@phosphorus.io> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Wed, 4 Oct 2017 15:54:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <8E6DE4EA-ADC8-434D-9BFD-87AFE2387DCE@phosphorus.io> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:1p+84j/LoBYFiwDXBPn8mya3lwCP4ZhtKDrcqLNhxYIQmNbQuU3 /szVS12LQznVU5Y4kAtVQ1yg1yl6Ea6iO2BA2Eig1R2iqooAULgX/higLx5nUFHZOukSsq4 r+3MG3pOGOtkSI0Dz8hS351DtxgZJp0NI3z+bCEW06gD4b+9JcuZGPFXSMVgf1AqFxxGrnp z+MToHNh2hACOoTGX6mgA== X-UI-Out-Filterresults: notjunk:1;V01:K0:CdFc7B/xWdI=:94UVVKRmWTfUE4tvgL0A7V 9IYzGnaA2M2vWIsyNCpIW0pW8fEL+X0JS6Y3IvmXtak2UVJt5WAbol7RlQf5zgvvJkSuNVin+ IasK9T+Gk/wOsc5Ps6I7uqn//JtQDPY2KKvnWWm57+s8tQLDD9ji8SIFSBYo8hfY/JkcJyIsn ATUJvafgn1C2kLGRWkpIRLRcAISfUKQQgveWfsx+S+0MBmXxh/cP0q4dtBoS+MElPYVUjAGb/ 6cNRZQHdj89St8BMfdvI782k/wwvXY11PDnpRAqIb/2pXYMbiE3nT6l0yarnqG/pwPqSKvIAG AGwW6zhM0VykM41iLT2Oa0cPqrhc1fW6gjDionwIb395Ks88LgKUjVq9rcL/xEGEw6jJEUPEM ATXpIxsH6+8KQtQOa2rBYsNl6OdIuWhQzUN+gZk5wWtyrO1JeWkpinAq93QDe6d5azR8B0ttB iHOM1lOSnQI0cOzqRXrzgr1LyZvMz3XB+/KfalNOrSsB0JQIZljRrY9KFZWwXpF3wec0hE0JF SGlfViE25/JLLOmf+WOxvY3DtZ9f74n722KQ0NbWAPzBTkzSxLBAFIYGJm9AnbXJ1ofCNSXvM zh+rT4LPSGtK8Pm2FwMf6zqcFS5bYqIdIRkT6SbpSLjuDmQ+gAWobXgPxll+6gykuVj67ucn6 uO+geE/traRTOUXkBMF7Z0XYmjZdHemz8a3tdp4fJH1teftu8Zqs7zdzjw9GHdbNPJcIzReWO eVVRUOT+Tmf4FWj1Wroo146Gr+rcR+funqLIH0FA88wiKQpGWK5uXVMrs+LceqrstBp5wcvVn XqLO00TMVrV/53xghUj9ZTmh/207mXW6S2/jrbsHYyBwKi8f3U= Archived-At: Subject: Re: [Fud] Editorial Charter Update X-BeenThere: fud@ietf.org 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: Wed, 04 Oct 2017 13:54:12 -0000 Hi Chris, my intention is to describe a reasonable starting point that helps solve a security problem in the IoT world. You have to start somewhere and I am sure there is more work to be done and charters can be extended over time as progress is being made. Furthermore, nothing is saying at the work will not be useful for other areas as well but it should at least define the core problem. I hope my clarification makes sense. Ciao Hannes On 10/01/2017 04:11 PM, Chris Rouland wrote: > > Hi, > > I do think that locking into the firmware binary itself could exclude a > significant part of the problem set around updating embedded IOT > operating systems that would not technically be classified as FW. > > I think SUIT is good and broad. > > > -Chris > > >> On Oct 1, 2017, at 3:20 AM, Emmanuel Baccelli >> > wrote: >> >> Hi Hannes, >> >> thanks for the update. Reads well in my opinion.  >> A couple of comments below: >> >> On Fri, Sep 29, 2017 at 1:00 PM, Hannes Tschofenig >> > wrote: >> >> >> >> Firmware Updating Description (FUD) >> [Alternative proposal: SUIT (Software Updates for Internet of >> Things).] >> >> >> To no surprise, I really like SUIT, but if the WG focuses only on >> firmware and excludes other types of software updates, we should >> probably keep that name for another working group ;) >> >> On the other hand, FUD is still a problematic name. How about an >> alternative such as: >> >> FiDeL : Firmware Description for Low-end IoT devices >> >> >> out of scope are >> software update solutions that aim to take the features of scripting >> languages, such as JavaScript variants like JerryScript, into account. >> >> >> FYI JerryScript is fully compliant with ECMA5.1, hence not really a >> "variant". >> Here, I don't think we need to be that precise anyway to get the >> message across. >> How about rephrasing with something like: >> >> "Software update solutions that target updating software other than >> the firmware binary (e.g. updating scripts) are out of scope". >> >> Cheers >> >> Emmanuel >>   >> _______________________________________________ >> Fud mailing list >> Fud@ietf.org >> https://www.ietf.org/mailman/listinfo/fud > > > > _______________________________________________ > Fud mailing list > Fud@ietf.org > https://www.ietf.org/mailman/listinfo/fud > From nobody Wed Oct 4 10:31:35 2017 Return-Path: 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 8981A132076 for ; Wed, 4 Oct 2017 10:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 1i1pwN0oqHK2 for ; Wed, 4 Oct 2017 10:31:31 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74B091326ED for ; Wed, 4 Oct 2017 10:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v94HVRnU018236; Wed, 4 Oct 2017 19:31:27 +0200 (CEST) Received: from [10.0.4.24] (unknown [94.142.34.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3y6jcZ3l0LzDLD8; Wed, 4 Oct 2017 19:31:26 +0200 (CEST) Content-Type: multipart/alternative; boundary=Apple-Mail-D349A029-3335-4259-AF13-981FA0EECB54 Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPhone Mail (15A402) In-Reply-To: <578DD8B8-E786-4913-AE6A-65FFA29019AD@vigilsec.com> Date: Wed, 4 Oct 2017 20:31:21 +0300 Cc: "Fud@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: <578DD8B8-E786-4913-AE6A-65FFA29019AD@vigilsec.com> To: Russ Housley Archived-At: Subject: Re: [Fud] Editorial Charter Update X-BeenThere: fud@ietf.org 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: Wed, 04 Oct 2017 17:31:33 -0000 --Apple-Mail-D349A029-3335-4259-AF13-981FA0EECB54 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Russ,=20 I had a comment about a possible misunderstanding of the FUD/suit WG being m= isunderstood as the rfc4108 bug fixing and tweaking WG. I'm not sure that ha= d been addressed. I'm mostly offline in the next seven days or so.=20 Sent from mobile > On 3. Oct 2017, at 16:43, Russ Housley wrote: >=20 > Here is an update to the charter text based on the comments. >=20 > Note that the WG name is still FUD. Any name change will be handled by th= e IESG. >=20 > Russ >=20 > =3D =3D =3D =3D =3D =3D =3D >=20 > Firmware Updating Description (FUD) > [Alternative proposal: SUIT (Software Updates for Internet of Things)] >=20 > Vulnerabilities in Internet of Things (IoT) devices have raised the > need for a secure firmware update mechanism that is also suitable for > constrained devices. Security experts, researchers, and regulators > recommend that all IoT devices be equipped with such a mechanism. While > there are many proprietary firmware update mechanisms in use today, there > is a lack of a modern interoperable approach of securely updating the > software in IoT devices. >=20 > A firmware update solution consists of several components, including: > * A mechanism to transport firmware images to IoT devices. > * A manifest that provides meta-data about the firmware image > (such as a firmware package identifier, the hardware the package > needs to run, and dependencies on other firmware packages), as > well as cryptographic information for protecting the firmware > image in an end-to-end fashion. > * The firmware image itself. >=20 > RFC 4108 provides a manifest format that uses the Cryptographic Message > Syntax (CMS) to protect firmware packages. >=20 > More than ten years have passed since the publication of RFC 4108, and > greater experience with IoT deployments has lead to additional > functionality, requiring the work done with RFC 4108 to be revisited. > The purpose of this group is to produce a second version of RFC 4108 > that reflects the current best practices. This group will focus on > defining a firmware update solution for Class 1 devices, as defined in > RFC 7228, that is -- IoT devices with ~10 KiB RAM and ~100 KiB flash. > This group will not define any transport mechanisms. >=20 > In June of 2016 the Internet Architecture Board organized a workshop on > 'Internet of Things (IoT) Software Update (IOTSU)', which took place at > Trinity College in Dublin, Ireland. The main goal of the workshop was > to foster a discussion on requirements, challenges, and solutions for > bringing software and firmware updates to IoT devices. This workshop > also made clear that there is a lack of regulatory requirements, which > contributes to challenges associated with misaligned incentives. It is > nevertheless seen as important to create standard building blocks that > help interested parties implement and deploy a solid firmware update > mechanism. >=20 > In particular this group aims to publish three documents, namely: > * An IoT firmware update architecture that includes a description of > the involved entities, security threats, and assumptions. > * The manifest format. > * A revision to RFC 4108 that reflects the current best practices. >=20 > This group will use draft-moran-fud-architecture as a starting point for > discussion of the "Architecture" document. >=20 > This group will use draft-moran-fud-manifest as a starting point for > discussion of the "Manifest Format" specification. >=20 > This group does not aim to create a standard for a generic software > update mechanism for use by rich operating systems, like Linux, but > instead this group will focus on software development practices in the > embedded industry. "Software update solutions that target updating > software other than the firmware binary (e.g. updating scripts) are > also out of scope. >=20 > This group will aim to develop a close relationship with silicon vendors > and OEMs that develop IoT operating systems. >=20 >=20 > Milestones: >=20 > Dec 2017 Submit RFC 4108bis document as WG item. >=20 > Dec 2017 Submit "Architecture" document as WG item. >=20 > Dec 2017 Submit "Manifest Format" specification as WG item. >=20 > Jul 2018 Submit "Architecture" to the IESG for publication as an > Informational RFC. >=20 > Nov 2018 Submit RFC 4108bis document to the IESG for publication as > a Proposed Standard. >=20 > Nov 2018 Submit "Manifest Format" to the IESG for publication as > a Proposed Standard. >=20 >=20 > Additional calendar items: >=20 > Mar 2018 Release initial version of the manifest creation tools as > open source. >=20 > Apr 2018 Release first version of manifest test tools as open > source. >=20 > Jun 2018 Release first IoT OS implementation of firmware update > mechanisms as open source. >=20 > _______________________________________________ > Fud mailing list > Fud@ietf.org > https://www.ietf.org/mailman/listinfo/fud >=20 --Apple-Mail-D349A029-3335-4259-AF13-981FA0EECB54 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Russ, 

I had a c= omment about a possible misunderstanding of the FUD/suit WG being misunderst= ood as the rfc4108 bug fixing and tweaking WG. I'm not sure that had been ad= dressed. I'm mostly offline in the next seven days or so. 

Sent from mob= ile

On 3. Oct 2017, at 16:43, Russ Housley <housley@vigilsec.com> wrote:

Here is an update to the charter tex= t based on the comments.

Note that the WG n= ame is still FUD.  Any name change will be handled by the IESG.<= br>
Russ

=3D =3D =3D =3D= =3D =3D =3D

Firmware Updating Description (= FUD)
[Alternative proposal: SUIT (Software Updates for Inter= net of Things)]

Vulnerabilities in Internet= of Things (IoT) devices have raised the
need for a secure f= irmware update mechanism that is also suitable for
constrain= ed devices.  Security experts, researchers, and regulators
recommend that all IoT devices be equipped with such a mechanism.  = While
there are many proprietary firmware update mechanisms i= n use today, there
is a lack of a modern interoperable appro= ach of securely updating the
software in IoT devices.=

A firmware update solution consists of several co= mponents, including:
 *  A mechanism to transport= firmware images to IoT devices.
 *  A manifest t= hat provides meta-data about the firmware image
  = ;  (such as a firmware package identifier, the hardware the packag= e
    needs to run, and dependencies on= other firmware packages), as
    well a= s cryptographic information for protecting the firmware
&nb= sp;   image in an end-to-end fashion.
 = *  The firmware image itself.

RFC 4108= provides a manifest format that uses the Cryptographic Message
Syntax (CMS) to protect firmware packages.

More than ten years have passed since the publication of RFC 4108, and
greater experience with IoT deployments has lead to additiona= l
functionality, requiring the work done with RFC 4108 to be= revisited.
The purpose of this group is to produce a second= version of RFC 4108
that reflects the current best practice= s.  This group will focus on
defining a firmware update= solution for Class 1 devices, as defined in
RFC 7228, that i= s -- IoT devices with ~10 KiB RAM and ~100 KiB flash.
This g= roup will not define any transport mechanisms.

In June of 2016 the Internet Architecture Board organized a workshop on<= /span>
'Internet of Things (IoT) Software Update (IOTSU)', which to= ok place at
Trinity College in Dublin, Ireland.  The ma= in goal of the workshop was
to foster a discussion on requir= ements, challenges, and solutions for
bringing software and f= irmware updates to IoT devices.  This workshop
also mad= e clear that there is a lack of regulatory requirements, which
contributes to challenges associated with misaligned incentives.  It= is
nevertheless seen as important to create standard buildi= ng blocks that
help interested parties implement and deploy a= solid firmware update
mechanism.
In particular this group aims to publish three documents, namely:
 *  An IoT firmware update architecture that include= s a description of
    the involved ent= ities, security threats, and assumptions.
 *  The= manifest format.
 *  A revision to RFC 4108 that= reflects the current best practices.

This g= roup will use draft-moran-fud-architecture as a starting point fordiscussion of the "Architecture" document.
This group will use draft-moran-fud-manifest as a starting point for<= /span>
discussion of the "Manifest Format" specification.
This group does not aim to create a standard for a g= eneric software
update mechanism for use by rich operating s= ystems, like Linux, but
instead this group will focus on sof= tware development practices in the
embedded industry.  = "Software update solutions that target updating
software oth= er than the firmware binary (e.g. updating scripts) are
also= out of scope.

This group will aim to devel= op a close relationship with silicon vendors
and OEMs that d= evelop IoT operating systems.


Milestones:

Dec 2017    =  Submit RFC 4108bis document as WG item.

Dec 2017     Submit "Architecture" document as WG ite= m.

Dec 2017     Submit "= Manifest Format" specification as WG item.

= Jul 2018     Submit "Architecture" to the IESG for publi= cation as an
       &nbs= p;    Informational RFC.

Nov 2018     Submit RFC 4108bis document to the IESG f= or publication as
       = ;     a Proposed Standard.
<= br>Nov 2018     Submit "Manifest Format" to the IE= SG for publication as
      &= nbsp;     a Proposed Standard.


Additional calendar items:

Mar 2018     Release initial version of th= e manifest creation tools as
     =        open source.

Apr 2018     Release first version of manife= st test tools as open
      &= nbsp;     source.

= Jun 2018     Release first IoT OS implementation of firm= ware update
        = ;    mechanisms as open source.
<= br>_______________________________________________
Fud= mailing list
Fud@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/fud

=
= --Apple-Mail-D349A029-3335-4259-AF13-981FA0EECB54-- From nobody Wed Oct 4 10:38:28 2017 Return-Path: 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 73DC7132076 for ; Wed, 4 Oct 2017 10:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=linaro.org 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 KTN0QHGsCBa5 for ; Wed, 4 Oct 2017 10:38:25 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 9180513304A for ; Wed, 4 Oct 2017 10:38:25 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id l15so11219670iol.8 for ; Wed, 04 Oct 2017 10:38:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=m/8vgNigvjGiVDXSK6B3WEzC8Ez+CKIg2mbNH834I64=; b=Cd5w/lg+FXATEyJsbhPfzfv1gB43VozDYVcs4CLxAUAYWcPWcPgAr3Gill+AAWNOhV 5GIyv8cXmcgwyse3GikqObMGl0O22OloT4XvYaWRxwGIzMI9JJ43pK2vObfMs7C48ubU ZS58uIqpOirlq6OsoBV4Hhls2cxroF/Rp2MIw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=m/8vgNigvjGiVDXSK6B3WEzC8Ez+CKIg2mbNH834I64=; b=RUHaiK8ivwHAsFDs4+te0FCXQ5tQkKoF6m1glrafMDptFGu0+PdbN99GraW42iR7Qj dEal61BGLVEDoOUkY/+ZqoCwSmDUP9/lzGTWpjB6HjQaWnqfBBhe/Ngyi2QB6c+AEYiy ibT/s8om6mTfO9cL7SPyNthzDO/40BewmLEItncjZTl4jVNAdbRvrC3+GWSe86Q2p3kz q0A9vzbmx4KTF0nGviTXxlWitA5aS0g4gkitkziMlGzeIx5mVuGF7VzY68Zuy2m0B4Rx XLCjxHEsmOFAfjBsSY5PEHaE8oJ8jgz+S5rf3XFgQzb5X1BQunM6MnMyEbFxrJpYvO89 GV6A== X-Gm-Message-State: AMCzsaX3ufzT6rtB9tQ16d4s1LFujvQo0Ig3XfZkzBUF33IRnuZ4KxSO NUbTUZ4KPur9gkpZI4fcc4yCXtBY1Tk= X-Google-Smtp-Source: AOwi7QAkagT0D/gnnBx0wJXEA3Hok3f83XyTquVg8WwzXSInsvCWNyvn1xK00193IBWffmjQhERW6Q== X-Received: by 10.107.164.31 with SMTP id n31mr438192ioe.46.1507138704553; Wed, 04 Oct 2017 10:38:24 -0700 (PDT) Received: from davidb.org ([2601:283:4300:dae1:31f7:2a2a:78a4:32be]) by smtp.gmail.com with ESMTPSA id e34sm7433612ioj.23.2017.10.04.10.38.23 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 04 Oct 2017 10:38:23 -0700 (PDT) Date: Wed, 4 Oct 2017 11:38:22 -0600 From: David Brown To: fud@ietf.org Cc: Emmanuel Baccelli , dev-mcuboot@lists.runtime.co, Hannes Tschofenig , housley@vigilsec.com, david.waltermire@nist.gov Message-ID: <20171004173822.hqin7lrbjyhuwvc3@davidb.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Fud] [dev-mcuboot] IoT firmware update standardization efforts @ IETF X-BeenThere: fud@ietf.org 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: Wed, 04 Oct 2017 17:38:27 -0000 On Fri, Sep 22, 2017 at 10:01:18AM +0200, Emmanuel Baccelli wrote: >Dear MCUbooters > >I wanted to bring your attention to an effort starting at IETF to standardize >some aspects fo firmware updates. > >I think it would be useful if some MCUboot/Zephyr/MyNewt could participate. > >The working group about to be created is called FUD [1]. >There are a couple of initial drafts [2] and a mailing list [3] through which >discussion happens, as usual for such efforts. > >FYI the next f2f meeting will be at IETF 100 [4]. Thanks for the information. I have joined the fud mailing list, and intend to become involved. I work on MCUboot as well as on the Zephyr project. MCUboot address a small part of the firmware update process, namely performing the atomic operation of the actual final firmware upgrade. It also supports additional features such as revert when an image is determined to be nonfunctional. MCUboot original came from the Mynewt project, and is a part of their update solution. The Zephyr project has not defined firmware update beyond porting MCUboot to Zephyr. As such, what is being discussed at FUD is very applicable. I'd also like to give a very short overview of MCUboot, since its existing image formats may need to change to accomodate a CMS formatted firmware package. The primary design constraint behind MCUboot's image format is the support for execute in place (XIP) MCU devices. Typically, these devices begin executing from an address at a vector near the beginning of flash. MCUboot is itself installed at the beginning of flash, and expects both the runnable image and the upgrade image to occupy partitions following this. The runnable application is modified from a standalone MCU application in several ways: - It is linked at an address for the runnable partition (referred to as Slot 0 in the MCUboot design documentation). - There is a small header at the beginning, with flags, a header size field, and an image size field. This can be used to compute the address of the end of the image. - After the image is a simple TLV-formatted encoding of a signature over the header and the image. In order to support a CMS formatted firmware image, MCUboot will need to take one of several approaches. - The firmware package will be unwrapped outside of the context of the bootloader. The content of the CMS payload would have the header and TLV signature already on it. This would require no modification to MCUboot, but may be difficult to implement in a RAM-constrained device that does not have sufficient RAM to hold the entire firmware package. - MCUboot could be modified to unpack the firmware package from the upgrade partition when copying it to the runnable partition. This would add complexity, as well as make MCUboot's current rollback mechanisms more complex. - The content inside of the firmware package could be designed to be executable directly out of the firmware package. With DER encoding, this will be somewhat complicated, as the length of the preceding data in the firmware package contains encoded values that depend on the length of the firmware package itself. There are possible implementations, such as repeating the link and package operation until a fixed point is reached. I hope to be able to bring useful feedback based on our experience with MCUboot and performing updates of this class of devices. Thanks, David Brown From nobody Wed Oct 4 13:30:29 2017 Return-Path: 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 463081342EE for ; Wed, 4 Oct 2017 13:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com 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 qUG_H8ABYw1m for ; Wed, 4 Oct 2017 13:30:23 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1DAB1332C8 for ; Wed, 4 Oct 2017 13:30:22 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_0213_01D33D14.DE9E4170" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1507149019; h=from:subject:to:date:message-id; bh=bBh5+kSbOytmvPowBUQlkjqM7eUgJG+zcXcs3H1d8zs=; b=bG+XraNqqIWvK8J9R/Qff8oVWk24VSiiirhoOAIak7emrHwxtL01JJuMHV0xcJBeqvQp4eow0Ts TuE693BiEqp/uMHNFLkxhi/cRI5olqEYzRzC3k//eJ4CvY32E5aBWz80sBMOO4fJGIpqR568zRz5r R7wo8yvU0GLnt0vzsO8LN+H0KwP6TOrF5C5eLCZ8EHa2jSCx6hMUomG1OH8OiUYWtdo72zLqO5wnn IEaZfudjGUMNVu9A8F5utNG7SwCEJ5qvq/y7WgUvqVoKFrHjX3gHKNd8L964C+OiqQx+KMfEvvq5G 50IpdHVSS1RJenTcglQMceNg5lRU0HkcWLpg== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 4 Oct 2017 13:30:18 -0700 Received: from Hebrews (173.8.216.38) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 4 Oct 2017 13:29:07 -0700 From: Jim Schaad To: References: <5D8BA40A-0A70-44BC-B136-6A8946F4A80B@vigilsec.com> In-Reply-To: <5D8BA40A-0A70-44BC-B136-6A8946F4A80B@vigilsec.com> Date: Wed, 4 Oct 2017 13:29:53 -0700 Message-ID: <021201d33d4f$8af662b0$a0e32810$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFIzdx4IdoVPeqc3QieDdoEAc8QRQI5vojWo9cnC5A= X-Originating-IP: [173.8.216.38] Archived-At: Subject: Re: [Fud] A few questions / observations X-BeenThere: fud@ietf.org 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: Wed, 04 Oct 2017 20:30:28 -0000 ------=_NextPart_000_0213_01D33D14.DE9E4170 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have been asked to respond to this =E2=80=93 so some comments inline =20 From: Russ Housley [mailto:housley@vigilsec.com]=20 Sent: Wednesday, October 4, 2017 6:53 AM To: Jim Schaad Subject: Fwd: [Fud] A few questions / observations =20 If you are not on the FUD mail list, please join at least for this part = of the discussion. =20 Russ =20 =20 Begin forwarded message: =20 From: Brendan Moran > Subject: Re: [Fud] A few questions / observations Date: October 4, 2017 at 9:39:57 AM EDT To: "Smith, Ned" > Cc: "Fud@ietf.org " > =20 Hi Ned, =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D COSE =20 I think that COSE could be very beneficial in environments where a = generic CBOR parser is available and a generic ASN.1 DER parser is not. = CBOR has a minor compactness improvement for basic, un-tagged types. I = expect COSE adoption to increase over the long term, barring some = unexpected problem with the encoding. HSMs are a moot point, since = I=E2=80=99m not aware of any support for either CMS or COSE directly on = an HSM. =20 I do have some concerns about the use of CBOR manifests with COSE = signatures for firmware updates. =20 1. Availability on microcontrollers The primary target of FUD/SUIT is microcontrollers. Each of OpenSSL, = mbedTLS, tinyDTLS contain a X.509 parser, which contains everything that = is needed for parsing a DER-encoded manifest=E2=80=94N.B. a schema is = still needed in each case. In fact, I would be surprised if there were a = TLS library available that doesn=E2=80=99t have an X.509 parser. That = suggests to me that DER parsers are effectively ubiquitous and that one = is already present on every device that is targeted by FUD, since it is = unlikely that there would be a FUD target without a TLS library. It may = be in the future that CBOR parsers and COSE certificates also become = ubiquitous, but it is too early to tell. [JLS] I think that at present it is true that the code for DER decoding = is present in all of these code bases. It may or may not be true that = the code makes it from the code base to the deployment. Many of the = people that I have talked to are looking at using either raw public keys = or pre-shared keys as the authentication mode for doing TLS. This means = that the need for any ASN.1 decoding goes away from TLS and the DER = encoder would not be needed on the end product. I think this might be a = YMMV statement. =20 2. Schemas In ASN.1, the meaning of a field is determined by its position in the = schema, so the semantics of any field are implicit. CBOR explicitly = states that no schema is needed, citing: [JLS} First let me address the statement that CBOR has that it does not = need a schema for decoding. This may not be the best of language in the = spec, but it does not refer the question of what many people think of as = the purpose of a schema. The issues with not requiring a schema are the = following: 1. Implicit tags in ASN.1 require that a schema be known by the decoder = in order to do the correct decoding. CBOR only has explicit tags and = thus the schema is not required 2. Default values in ASN.1 require that the schema be known if the = decoder is going to fill in a location in a structure with the correct = value. The default value is omitted from the encoded format and thus = needs to be supplied by the decoder. CBOR does not support default = values. Any defaulting in maps is required to be done at the = application level. 3. Some of the ASN.1 encoding formats, PER comes to mind, require = knowledge of the schema in order to correctly get the encoding and = decoding correct as the encoded format needs to have information about = such things as the range of values in order to decode things. CBOR does = not have this type of encoding so a schema is not required. This said, there is a schema language (CDDL) that is being developed for = CBOR. The question therefore when you think of a schema is are you = looking at just describing where things are, in which case CBOR and = ASN.1 are going to have the same properties, or are you using it to try = and omit or shrink the final output, in which case CBOR is not going to = support it. =20 > This works much better in a world where both ends of a communication = relationship may be evolving at high speed. =20 While I do anticipate that this is useful in many circumstances, = I=E2=80=99m not convinced that it is accurate in Firmware Update. The = lack of schema causes several problems: a) In order to identify a particular field in a group at the same = nesting level, CBOR uses maps. Maps require an additional type per = field. This eliminates any savings in size that are granted by the = compactness of CBOR=E2=80=99s basic type encoding. [JLS] CBOR has both maps and arrays. Maps correspond to SETs while = arrays correspond to SEQUENCEs. Both can be used and thus there is no = requirement that everything be a map. This means that the size savings = is still preserved. =20 b) If a particular map is parsed and then re-encoded, it may not = re-encode the same way as it was originally encoded. This causes = problems from a signature verification perspective, and it is the reason = that ASN.1 DER was derived from ASN.1 BER. [JLS] This is a problem at the moment. There is a preliminary version = of conical encoding for CBOR that exists, and which I personally do not = like, so it is always possible that one can allow for re-encoding. = However, to be honest the very idea of decoding and re-encoding is = probably not something that should be relied on to any extent. With = certificates there have been far too many examples of people who either = did not use DER or got the DER encoding wrong so that doing a decode and = then later re-encoding caused all sorts of problems. I have found it = far more convenient to do what both CMS and COSE do for these cases = which is to wrap things in a binary blob and do multiple passes of = decoding to make sure that if it was not encoding correctly it will = still validate. =20 c) Even without a formal schema, an informal schema must be created. = Whether this is existence checks or non-existence checks, it leaves the = schema up to each implementor, which can be error-prone. A formal schema = is a much more robust error checking mechanism, particularly if it is = possible to generate the parser directly from the schema. [JLS} The ability to create code and structures from a schema is one of = the things that I have found to be extremely useful with ASN.1. I = regret that this is not currently considered to be a priority with CDDL = at the moment although this may change in the future. With some = restrictions, it would be possible to come up with a CBOR encoding = method for ASN.1 but as this does not currently seem where that world is = going I have not even done more than a preliminary look at what things = would look like. When I did do it I found that the data models are not = quite aligned so it does cause some problems. However, it should be = possible to have both an ASN.1 and a CDDL schema which are going to look = close enough to each other to be used. I do agree that a machine = readable schema format is a huge win despite what some other say. =20 =20 d) Devices may support this format for more than 20 years, so a rapidly = changing environment is not helpful. A schema that can be tested against = helps when future implementations need to be tested for backwards = compatibility. =20 Therefore, if COSE were to be used, I believe that we should use a = schema with the CBOR manifest. Perhaps, if that were the case, there = might be a DML that is both descriptive enough to layout a CBOR = manifest, and has enough tooling to generate a specialised C CBOR parser = explicitly for the manifest. =20 3. Maturity CMS has been in use since at least 1998 (as PKCS7 before that) and has = broad support and validation. This has provided time for problems such = as those detailed in RFC6211 to be identified and corrected. COSE was = proposed in 2015 and standardised in July 2017. CMS is a far more mature = standard than COSE. This is not to say that COSE doesn=E2=80=99t have = advantages over CMS. Simply that CMS has an enormous number of deployed = instances and an enormous quantity of testing behind it. [JLS] I am sure you have already noticed that the author of COSE and the = author of RFC 6211 are the same individual. COSE has benefited from = many of the developments and problems that have been identified over = time in CMS and is going to be around the same level of maturity from = that standpoint. I would be foolish to claim that I have gotten all of = the problems of COSE worked out, but I do not believe that it is going = to be any less problematic over time. That said,, I do completely agree = that there is a much greater amount of deployment and use of CMS and = that is a big advantage =20 Ultimately, I think that CBOR/COSE will become very useful for this sort = of use-case. At the moment, however, I think that ASN.1 DER/CMS is the = pragmatic choice, due to availability on MCUs, availability of a = DML/schema language with relevant tooling, and the maturity of the = format. =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 HSMs: =20 On the role of HSMs in firmware update: Please consider the use of smart = cards, hardware tokens, and other smart-card equivalents. This class of = device is both effectively an HSM and intended as a message processor. =20 One of the threats to firmware update I have considered is the exposure = of a developer private key, either via exfiltration of the key itself, = or through remote access to the developer machine. Should this happen, = the full fleet of devices for which the developer has access rights = could be compromised. Given that smart cards and hardware tokens are = available, low cost, and mitigate this threat by hosting private keys, = it would seem prudent to use them for large scale production = environments. =20 This is not to say that the use of HSMs should be mandated, but that any = solution should make it easy to use them. =20 =20 Thanks, =20 Brendan On 27 Sep 2017, at 01:01, Smith, Ned > wrote: =20 See additional comments inline below. -Ned =20 From: Brendan Moran < = Brendan.Moran@arm.com> Date: Tuesday, September 26, 2017 at 1:54 PM To: "Smith, Ned" < ned.smith@intel.com> Cc: " Fud@ietf.org" < = Fud@ietf.org> Subject: Re: [Fud] A few questions / observations =20 Hi Ned, I=E2=80=99ve placed my comments inline. =20 Thanks for your feedback! =20 Best Regards, Brendan =20 =20 On 15 Sep 2017, at 16:29, Smith, Ned < = ned.smith@intel.com> wrote: [stuff deleted] * Why was ASN.1 selected as the encoding format? (Why not COSE?) =20 ASN.1 was used for a few reasons. 1. It is the default format for certificates. Most tools use DER rather = than COSE for packing certificates, so this reduces the number of = parsers in the target. Where interwork with HSMs is involved, using a = format the HSM supports is beneficial. [nms] HSMs are a computing environment that is constrained to operations = involving mostly cryptographic and key exchange operations. Your = observation is that ASN.1 is the data model language of choice by the = HSM community. I agree that is the correct choice for that constrained = environment. However, it is also the case that there are other = environments that have chosen different data model languages and operate = in a constrained environment. COSE, JSON and XML are commonly available = parsers in these other environments. The logic that argues for = propagation of ASN.1 because the HSM =E2=80=9Cconstrained environment = already supports it and therefore avoids =E2=80=98bloat=E2=80=99 of an = additional parser=E2=80=9D can be used to argue the other side as well. = Since the constrained device already supports an alternative (e.g. COSE, = JSON, XML=E2=80=A6) and the dependence on ASN.1 represents additional = overhead to the constrained environment. In cases where both an = application processor and HSM environments exist it makes sense to use = one or the other or both, but not introduce a third. I=E2=80=99m not = taking a strong position on ASN.1 vs. COSE (or some other alternative) = except to observe that it shouldn=E2=80=99t be the objective of FUD to = advocate a particular data model language over another, but rather = should try to accommodate the data model language choices of the = constrained environments for which this RFC hopes to be relevant. It = should be noted that most data model languages that embrace security = typically make accommodation for a security DML by encapsulating PKCS = and X.509 - implying ASN.1/BER/DER support exists somewhere in the = platform. However, support for PKCS/X.509 should translate to general = and broad support for anything ASN.1 as the range of objects known to = PKCS and X.509 is typically rather small. My opinion is the environment that generates, distributes and installs = software updates isn=E2=80=99t entirely HSM or application framework = (e.g. LWM2M). Therefore, it is reasonable to expect multiple encodings = may be required. 2. PCKS7 / CMS / RFC5652 are widely supported. For example, = OpenSSL=E2=80=99s smime command handles CMS signing/validation directly. = This makes the custom tooling required simpler. This will also, = hopefully, improve compatibility with existing HSMs [nms] It is also the case that constrained environments may not have = chosen OpenSSL, but instead rely on embedTLS, tinyDTLS or other library = that doesn=E2=80=99t have the same dependency on SMIME. Compatibility = with HSMs is important, but the question for FUD potentially is to = understand how much of the RFC=E2=80=99s solution should be computed = within the HSM vs. the host processing environment or an available TEE. 3. Direct code generation. In a scenario where the parser does not = create a document object model, but extracts or validates specific = fields, ASN.1 provides a grammar that makes it possible to generate a = parser programmatically. [nms] It is true that the ASN.1 tools ecosystem is mature. ASN.1 has = been around for a while. That however has not prevented the invention = and proliferation of alternative data model languages. If the argument = is that ASN.1 will eventually win, we just need to wait longer, then I = respectfully disagree. The ecosystems supporting alternative DMLs may be = less mature, but they are evolving quickly. 4. The meaning of =E2=80=9Clength=E2=80=9D for composite types. In DER, = the length of a field is unambiguous. It is always the length, in bytes, = of the contained object. This allows a parser that understands the = document being parsed to skip large chunks of a deeply nested tree. In = CBOR, the =E2=80=9Clength=E2=80=9D of an array or map is the number of = elements it contains. This makes it impossible for the parser to = =E2=80=9Cskip=E2=80=9D anything. It has to parse the entire structure. = It is possible to circumvent some of these limitations using tagging, in = particular tag 24 (encoded CBOR data item), but this has the downside of = breaking translatability to JSON, which is a key advantage of CBOR. = Consistent TLV representation makes parsing in a constrained environment = offers a notional performance improvement, but this is minor and may not = play out in practice. [nms] The question to ask is whether this sort of parsing inefficiency = is a larger pain point than having to do semantic mapping of structures = that already are meaningful in the context of the application = environment that is performing the update. In such a case, ASN.1 may be = the greater pain point. =20 Never the less, I think that CBOR/COSE would be perfectly serviceable = for this use. I=E2=80=99m not even certain that ASN.1 can=E2=80=99t be = used as a schema for CBOR (see 3 above). That being the case, I can see = a case for DER manifests with CMS, and CBOR manifests with COSE. =20 [nms] Given COSE encodes X.509 and PKCS structures it would = seem the designers anticipated interoperation with HSMs, at least at the = key and certificate levels of abstraction. But given COSE defines a = cryptographic message syntax of its own, it anticipates relevance in = messaging processor environments. My understanding of HSMs are that they = don=E2=80=99t anticipate being used as message processors. My question = may be a bit more philosophical. Do the authors of the RFC regard the = exchange of SW updates and their manifests as being fundamentally an HSM = workload or something else; such as device management or possibly a = distributed compute? Thx, Ned =20 _______________________________________________ Fud mailing list Fud@ietf.org = https://www.ietf.org/mailman/listinfo/fud IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you.=20 IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you.=20 _______________________________________________ Fud mailing list Fud@ietf.org =20 https://www.ietf.org/mailman/listinfo/fud =20 ------=_NextPart_000_0213_01D33D14.DE9E4170 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I have = been asked to respond to this =E2=80=93 so some comments = inline

 

From: Russ = Housley [mailto:housley@vigilsec.com]
Sent: Wednesday, = October 4, 2017 6:53 AM
To: Jim Schaad = <ietf@augustcellars.com>
Subject: Fwd: [Fud] A few = questions / observations

 

If you are = not on the FUD mail list, please join at least for this part of the = discussion.

 

Russ

 

 



Begin forwarded message:

 

From: Brendan Moran <Brendan.Moran@arm.com>

Subject: Re: [Fud] A few = questions / observations

Date: October 4, 2017 at 9:39:57 = AM EDT

To: "Smith, Ned" = <ned.smith@intel.com>

Cc: "Fud@ietf.org" <Fud@ietf.org>

 

Hi Ned,

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

COSE

 

I = think that COSE could be very beneficial in environments where a generic = CBOR parser is available and a generic ASN.1 DER parser is not. CBOR has = a minor compactness improvement for basic, un-tagged types. I expect = COSE adoption to increase over the long term, barring some unexpected = problem with the encoding. HSMs are a moot point, since I=E2=80=99m not = aware of any support for either CMS or COSE directly on an = HSM.

 

I = do have some concerns about the use of CBOR manifests with COSE = signatures for firmware updates.

 

1. Availability on = microcontrollers

The = primary target of FUD/SUIT is microcontrollers. Each of OpenSSL, = mbedTLS, tinyDTLS contain a X.509 parser, which contains everything that = is needed for parsing a DER-encoded manifest=E2=80=94N.B. a schema is = still needed in each case. In fact, I would be surprised if there were a = TLS library available that doesn=E2=80=99t have an X.509 parser. That = suggests to me that DER parsers are effectively ubiquitous and that one = is already present on every device that is targeted by FUD, since it is = unlikely that there would be a FUD target without a TLS library. It may = be in the future that CBOR parsers and COSE certificates also become = ubiquitous, but it is too early to tell.

[JLS] I think that at = present it is true that the code for DER decoding is present in all of = these code bases.=C2=A0 It may or may not be true that the code makes it = from the code base to the deployment.=C2=A0 Many of the people that I = have talked to are looking at using either raw public keys or pre-shared = keys as the authentication mode for doing TLS.=C2=A0 This means that the = need for any ASN.1 decoding goes away from TLS and the DER encoder would = not be needed on the end product.=C2=A0 I think this might be a YMMV = statement.

 

2. Schemas

In ASN.1, the meaning of a field is determined by its = position in the schema, so the semantics of any field are implicit. CBOR = explicitly states that no schema is needed, citing:

[JLS}=C2=A0 First let me = address the statement that CBOR has that it does not need a schema for = decoding.=C2=A0 This may not be the best of language in the spec, but it = does not refer the question of what many people think of as the purpose = of a schema.=C2=A0 The issues with not requiring a schema are the = following:

  1. Implicit tags in = ASN.1 require that a schema be known by the decoder in order to do the = correct decoding.=C2=A0 CBOR only has explicit tags and thus the schema = is not required
  2. Default values in = ASN.1 require that the schema be known if the decoder is going to fill = in a location in a structure with the correct value.=C2=A0 The default = value is omitted from the encoded format and thus needs to be supplied = by the decoder.=C2=A0 CBOR does not support default values.=C2=A0 Any = defaulting in maps is required to be done at the application = level.
  3. Some of the ASN.1 = encoding formats, PER comes to mind, require knowledge of the schema in = order to correctly get the encoding and decoding correct as the encoded = format needs to have information about such things as the range of = values in order to decode things.=C2=A0 CBOR does not have this type of = encoding so a schema is not required.

This said, there is a = schema language (CDDL) that is being developed for CBOR. =C2=A0The = question therefore when you think of a schema is are you looking at just = describing where things are, in which case CBOR and ASN.1 are going to = have the same properties, or are you using it to try and omit or shrink = the final output, in which case CBOR is not going to support = it.

 

> This works much better in a world where both = ends of a communication relationship may be evolving at high = speed.

 

While I do anticipate that this is useful in many = circumstances, I=E2=80=99m not convinced that it is accurate in Firmware = Update. The lack of schema causes several = problems:

a) In order to = identify a particular field in a group at the same nesting level, CBOR = uses maps. Maps require an additional type per field. This eliminates = any savings in size that are granted by the compactness of = CBOR=E2=80=99s basic type encoding.

[JLS]=C2=A0 CBOR has = both maps and arrays.=C2=A0 Maps correspond to SETs while arrays = correspond to SEQUENCEs.=C2=A0 Both can be used and thus there is no = requirement that everything be a map.=C2=A0 This means that the size = savings is still preserved.

 

b) If a particular map is parsed and then re-encoded, = it may not re-encode the same way as it was originally encoded. This = causes problems from a signature verification perspective, and it is the = reason that ASN.1 DER was derived from ASN.1 BER.

[JLS] This is a problem = at the moment.=C2=A0 There is a preliminary version of conical encoding = for CBOR that exists, and which I personally do not like, so it is = always possible that one can allow for re-encoding.=C2=A0 However, to be = honest the very idea of decoding and re-encoding is probably not = something that should be relied on to any extent.=C2=A0 With = certificates there have been far too many examples of people who either = did not use DER or got the DER encoding wrong so that doing a decode and = then later re-encoding caused all sorts of problems.=C2=A0 I have found = it far more convenient to do what both CMS and COSE do for these cases = which is to wrap things in a binary blob and do multiple passes of = decoding to make sure that if it was not encoding correctly it will = still validate.

 

c) Even without a formal schema, an informal schema = must be created. Whether this is existence checks or non-existence = checks, it leaves the schema up to each implementor, which can be = error-prone. A formal schema is a much more robust error checking = mechanism, particularly if it is possible to generate the parser = directly from the schema.

[JLS} The ability to create code and structures = from a schema is one of the things that I have found to be extremely = useful with ASN.1.=C2=A0 I regret that this is not currently considered = to be a priority with CDDL at the moment although this may change in the = future.=C2=A0 With some restrictions, it would be possible to come up = with a CBOR encoding method for ASN.1 but as this does not currently = seem where that world is going I have not even done more than a = preliminary look at what things would look like.=C2=A0 When I did do it = I found that the data models are not quite aligned so it does cause some = problems.=C2=A0 However, it should be possible to have both an ASN.1 and = a CDDL schema which are going to look close enough to each other to be = used.=C2=A0 I do agree that a machine readable schema format is a huge = win despite what some other say.=C2=A0

 

d) Devices may support this format for more than 20 = years, so a rapidly changing environment is not helpful. A schema that = can be tested against helps when future implementations need to be = tested for backwards compatibility.

 

Therefore, if COSE were to be used, I believe that we = should use a schema with the CBOR manifest. Perhaps, if that were the = case, there might be a DML that is both descriptive enough to layout a = CBOR manifest, and has enough tooling to generate a specialised C CBOR = parser explicitly for the manifest.

 

3. Maturity

CMS has been in use since at least 1998 (as PKCS7 = before that) and has broad support and validation. This has provided = time for problems such as those detailed in RFC6211 to be identified and = corrected. COSE was proposed in 2015 and standardised in July 2017. CMS = is a far more mature standard than COSE. This is not to say that COSE = doesn=E2=80=99t have advantages over CMS. Simply that CMS has an = enormous number of deployed instances and an enormous quantity of = testing behind it.

[JLS] I am sure you have already noticed that = the author of COSE and the author of RFC 6211 are the same = individual.=C2=A0 COSE has benefited from many of the developments and = problems that have been identified over time in CMS and is going to be = around the same level of maturity from that standpoint.=C2=A0 I would be = foolish to claim that I have gotten all of the problems of COSE worked = out, but I do not believe that it is going to be any less problematic = over time.=C2=A0 That said,, I do completely agree that there is a much = greater amount of deployment and use of CMS and that is a big = advantage

 

Ultimately, I think that CBOR/COSE will become very = useful for this sort of use-case. At the moment, however, I think that = ASN.1 DER/CMS is the pragmatic choice, due to availability on MCUs, = availability of a DML/schema language with relevant tooling, and the = maturity of the format.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

HSMs:

 

On the role of HSMs in firmware update: Please = consider the use of smart cards, hardware tokens, and other smart-card = equivalents. This class of device is both effectively an HSM and = intended as a message processor.

 

One of the threats to firmware update I have = considered is the exposure of a developer private key, either via = exfiltration of the key itself, or through remote access to the = developer machine. Should this happen, the full fleet of devices for = which the developer has access rights could be compromised. Given that = smart cards and hardware tokens are available, low cost, and mitigate = this threat by hosting private keys, it would seem prudent to use them = for large scale production environments.

 

This is not to say that the use of HSMs should be = mandated, but that any solution should make it easy to use = them.

 

 

Thanks,

 

Brendan

On 27 Sep 2017, at 01:01, Smith, Ned <ned.smith@intel.com> = wrote:

 

See additional comments inline below.

-Ned

 

From: Brendan Moran <Brendan.Moran@arm.com>
Date: Tuesday, September = 26, 2017 at 1:54 PM
To: "Smith, Ned" = <ned.smith@intel.com>
Cc: "Fud@ietf.org" <Fud@ietf.org>
Subject: Re: [Fud] A few questions = / observations

 

Hi = Ned,

I=E2=80=99ve placed my comments = inline.

 

Thanks = for your feedback!

 

Best = Regards,

Brendan

 

 

On 15 Sep = 2017, at 16:29, Smith, Ned <ned.smith@intel.com> = wrote:

[stuff = deleted]

=C2=B7         Why was ASN.1 selected = as the encoding format? (Why not COSE?)

<= div>

 

ASN.1 was = used for a few reasons.

  1. It is the = default format for certificates. Most tools use DER rather than COSE for = packing certificates, so this reduces the number of parsers in the = target. Where interwork with HSMs is involved, using a format the HSM = supports is beneficial.

[nms] = HSMs are a computing environment that is constrained to operations = involving mostly cryptographic and key exchange operations. Your = observation is that ASN.1 is the data model language of choice by the = HSM community. I agree that is the correct choice for that constrained = environment. However, it is also the case that there are other = environments that have chosen different data model languages and operate = in a constrained environment. COSE, JSON and XML are commonly available = parsers in these other environments. The logic that argues for = propagation of ASN.1 because the HSM =E2=80=9Cconstrained environment = already supports it and therefore avoids =E2=80=98bloat=E2=80=99 of an = additional parser=E2=80=9D can be used to argue the other side as well. = Since the constrained device already supports an alternative (e.g. COSE, = JSON, XML=E2=80=A6) and the dependence on ASN.1 represents additional = overhead to the constrained environment. In cases where both an = application processor and HSM environments exist it makes sense to use = one or the other or both, but not introduce a third. I=E2=80=99m not = taking a strong position on ASN.1 vs. COSE (or some other alternative) = except to observe that it shouldn=E2=80=99t be the objective of FUD to = advocate a particular data model language over another, but rather = should try to accommodate the data model language choices of the = constrained environments for which this RFC hopes to be relevant. It = should be noted that most data model languages that embrace security = typically make accommodation for a security DML by encapsulating PKCS = and X.509 - implying ASN.1/BER/DER support exists somewhere in the = platform. However, support for PKCS/X.509 should translate to general = and broad support for anything ASN.1 as the range of objects known to = PKCS and X.509 is typically rather = small.

My = opinion is the environment that generates, distributes and installs = software updates isn=E2=80=99t entirely HSM or application framework = (e.g. LWM2M). Therefore, it is reasonable to expect multiple encodings = may be required.

  1. PCKS7 / = CMS / RFC5652 are widely supported. For example, OpenSSL=E2=80=99s smime = command handles CMS signing/validation directly. This makes the custom = tooling required simpler. This will also, hopefully, improve = compatibility with existing HSMs

[nms] It = is also the case that constrained environments may not have chosen = OpenSSL, but instead rely on embedTLS, tinyDTLS or other library that = doesn=E2=80=99t have the same dependency on SMIME. Compatibility with = HSMs is important, but the question for FUD potentially is to understand = how much of the RFC=E2=80=99s solution should be computed within the HSM = vs. the host processing environment or an available = TEE.

  1. Direct = code generation. In a scenario where the parser does not create a = document object model, but extracts or validates specific fields, ASN.1 = provides a grammar that makes it possible to generate a parser = programmatically.

[nms] It = is true that the ASN.1 tools ecosystem is mature. ASN.1 has been around = for a while. That however has not prevented the invention and = proliferation of alternative data model languages. If the argument is = that ASN.1 will eventually win, we just need to wait longer, then I = respectfully disagree. The ecosystems supporting alternative DMLs may be = less mature, but they are evolving = quickly.

  1. The = meaning of =E2=80=9Clength=E2=80=9D for composite types. In DER, the = length of a field is unambiguous. It is always the length, in bytes, of = the contained object. This allows a parser that understands the document = being parsed to skip large chunks of a deeply nested tree. In CBOR, the = =E2=80=9Clength=E2=80=9D of an array or map is the number of elements it = contains. This makes it impossible for the parser to = =E2=80=9Cskip=E2=80=9D anything. It has to parse the entire structure. = It is possible to circumvent some of these limitations using tagging, in = particular tag 24 (encoded CBOR data item), but this has the downside of = breaking translatability to JSON, which is a key advantage of CBOR. = Consistent TLV representation makes parsing in a constrained environment = offers a notional performance improvement, but this is minor and may not = play out in practice.

[nms] The = question to ask is whether this sort of parsing inefficiency is a larger = pain point than having to do semantic mapping of structures that already = are meaningful in the context of the application environment that is = performing the update. In such a case, ASN.1 may be the greater pain = point.

 

Never the = less, I think that CBOR/COSE would be perfectly serviceable for this = use. I=E2=80=99m not even certain that ASN.1 can=E2=80=99t be used as a = schema for CBOR (see 3 above). That being the case, I can see a case for = DER manifests with CMS, and CBOR manifests with = COSE.

 

          = ;  [nms] Given COSE encodes X.509 and PKCS structures it would seem = the designers anticipated interoperation with HSMs, at least at the key = and certificate levels of abstraction. But given COSE defines a = cryptographic message syntax of its own, it anticipates relevance in = messaging processor environments. My understanding of HSMs are that they = don=E2=80=99t anticipate being used as message processors. My question = may be a bit more philosophical. Do the authors of the RFC regard the = exchange of SW updates and their manifests as being fundamentally an HSM = workload or something else; such as device management or possibly a = distributed compute?


Thx,

Ned


 

_______________________________________________
Fud mailing list
Fud@ietf.org
<= span style=3D'font-size:12.0pt;font-family:"Times New Roman",serif'>https://www.ietf.org/mailman/listinfo/fud


IMPORTANT NOTICE: The contents of this email and any = attachments are confidential and may also be privileged. If you are not = the intended recipient, please notify the sender immediately and do not = disclose the contents to any other person, use it for any purpose, or = store or copy the information in any medium. Thank you. 


IMPORTANT NOTICE: The = contents of this email and any attachments are confidential and may also = be privileged. If you are not the intended recipient, please notify the = sender immediately and do not disclose the contents to any other person, = use it for any purpose, or store or copy the information in any medium. = Thank you.

_______________________________________________
Fud = mailing list
Fud@ietf.org
https://www.ietf.org/m= ailman/listinfo/fud

 

------=_NextPart_000_0213_01D33D14.DE9E4170-- From nobody Thu Oct 5 14:21:32 2017 Return-Path: X-Original-To: fud@ietf.org Delivered-To: fud@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 25736132D44; Thu, 5 Oct 2017 14:21:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: Kathleen.Moriarty.ietf@gmail.com, fud@ietf.org, smccammon@amsl.com, fud-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150723849007.6015.7914848333006431905.idtracker@ietfa.amsl.com> Date: Thu, 05 Oct 2017 14:21:30 -0700 Archived-At: Subject: [Fud] fud - Update to a Meeting Session Request for IETF 100 X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 21:21:30 -0000 An update to a meeting session request has just been submitted by Stephanie McCammon, on behalf of the fud working group. --------------------------------------------------------- Working Group Name: Firmware UpDate Area Name: Security Area Session Requester: Stephanie McCammon Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: curdle sipbrandy ipwave stir sipcore ipsecme tls acme lamps mile sacm anima Second Priority: dispatch oauth saag ace uta tcpinc perc netmod Third Priority: mtgvenue iasa20 People who must be present: Russ Housley Kathleen Moriarty David Waltermire Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Oct 9 01:27:24 2017 Return-Path: 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 00CC0134CAD for ; Mon, 9 Oct 2017 01:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-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 R_Alv4lKJP1N for ; Mon, 9 Oct 2017 01:27:19 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 264D5134CF0 for ; Mon, 9 Oct 2017 01:24:36 -0700 (PDT) Received: from [192.168.91.203] ([80.92.122.248]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LuKHz-1dJvTk0o8l-011fFc; Mon, 09 Oct 2017 10:24:23 +0200 To: Carsten Bormann , Russ Housley Cc: "Fud@ietf.org" References: <578DD8B8-E786-4913-AE6A-65FFA29019AD@vigilsec.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <66e408f7-44b5-b1a3-a53b-82454b8260a4@gmx.net> Date: Mon, 9 Oct 2017 10:24:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:DLa0rtJ2hkMfK7/ZGUkKjC0xSABuWv5L50caf1mdjYZTsaXNqXY sSpFabNYuhSPArsKVjwZHyesb02QeRC3Q+YoZIZ7wyFXbauxtqJ1SSs1WVPFtXdbR38LUiu Vx3+cbAC5L5rJgAplIdkFD+e5vcVMaUvt8KelgvESePVTBgXhGTS7R6jeO0YS8QJ7X/VcyA gYcIzjm7OBgpa7DewOwAw== X-UI-Out-Filterresults: notjunk:1;V01:K0:OYF/z9v3PtA=:Yj6xUsvkjV1/v72JY/ACKb UpGmuiHpOPxtsZkZLsv5/u6OdhsLk1k5+q6lXecVJLDnADM1vJ3EUmJRNHKvL+SBor2CvQh/Q bBaPT1T0owpY0egybXtuff0rdaKQ1Ysb/dH0QUawu7ePkY06jz/gAF5u0V6yhK97+sXgdH4My QQkDxei0VqbYG/+vJbsAYDFtOlB/9o4ILkQ2Km+ZrnsJ0zwNVsg1t4R9ps9I4tJuBWGq0GKOb eWqkWKUvKJbHFc35yggNiBAa1J+QYk2ftCTu383ffMuBDGctrLSuRXiF0ze6sPX1ipUPdPYt/ EvA9WKCL7JIjXUm+N6xfe0nEEFKXFC80ZP7rtETvPeAw6Gdmg8nydLeWP5qlAHGEC20ur7FAs Sap0zJsCdGL+A81YXRqKPz6iqorr6dwjDfzbg7MybEcjVoPLMDmnX3igSe73RvgRxBzsqnYIC bCe6I+1aiJV5oPr8s57zqH7EaaQj1yBtzBnySHz3wDEwlOxpFCMrZ5DLW9A4FrCREflv3QTiG 2idl9JaHIpvZU9H7bCxKvBhHW464YqW+dpb+ZqXOC200iPP8cdLftnlfuqYUFK/dwO0qCYvKL 3aVW/1gnhTYh/xYsKmsIv881LVutrT0fCKbV7e7vT29n/a77x++r4sVbK1N9nVvs4w9jU6aKs /3ug/xcMR/QgeL5UsjtHmGALysTBPs6mKavhlphnMBE2S7iKD4q7pJKFiCs241mLJCDoO+f16 jJ8+mJU3K3XAlO798mi1lPqR1jWglYC9nUr7jXYMCH0J4YcZ206W/N5ZDVem8TUlh29r7fwJw jUvqfpQwqgYZlfKo6F6vZaRwPABirv1a8GfMkzeVj3y5F0LRRk= Archived-At: Subject: Re: [Fud] Editorial Charter Update X-BeenThere: fud@ietf.org 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: Mon, 09 Oct 2017 08:27:22 -0000 Hi Carsten I had provided a response to your comment and asked whether it clarifies things. I don't believe you have responded. So far, I haven't heard you saying anything about what you would like to see done in this working group. I would also like to know what you see wrong with bug fixing and tweaking? Ciao Hannes On 10/04/2017 07:31 PM, Carsten Bormann wrote: > Hi Russ,  > > I had a comment about a possible misunderstanding of the FUD/suit WG > being misunderstood as the rfc4108 bug fixing and tweaking WG. I'm not > sure that had been addressed. I'm mostly offline in the next seven days > or so.  > > Sent from mobile > > On 3. Oct 2017, at 16:43, Russ Housley > wrote: > >> Here is an update to the charter text based on the comments. >> >> Note that the WG name is still FUD.  Any name change will be handled >> by the IESG. >> >> Russ >> >> = = = = = = = >> >> Firmware Updating Description (FUD) >> [Alternative proposal: SUIT (Software Updates for Internet of Things)] >> >> Vulnerabilities in Internet of Things (IoT) devices have raised the >> need for a secure firmware update mechanism that is also suitable for >> constrained devices.  Security experts, researchers, and regulators >> recommend that all IoT devices be equipped with such a mechanism.  While >> there are many proprietary firmware update mechanisms in use today, there >> is a lack of a modern interoperable approach of securely updating the >> software in IoT devices. >> >> A firmware update solution consists of several components, including: >>  *  A mechanism to transport firmware images to IoT devices. >>  *  A manifest that provides meta-data about the firmware image >>     (such as a firmware package identifier, the hardware the package >>     needs to run, and dependencies on other firmware packages), as >>     well as cryptographic information for protecting the firmware >>     image in an end-to-end fashion. >>  *  The firmware image itself. >> >> RFC 4108 provides a manifest format that uses the Cryptographic Message >> Syntax (CMS) to protect firmware packages. >> >> More than ten years have passed since the publication of RFC 4108, and >> greater experience with IoT deployments has lead to additional >> functionality, requiring the work done with RFC 4108 to be revisited. >> The purpose of this group is to produce a second version of RFC 4108 >> that reflects the current best practices.  This group will focus on >> defining a firmware update solution for Class 1 devices, as defined in >> RFC 7228, that is -- IoT devices with ~10 KiB RAM and ~100 KiB flash. >> This group will not define any transport mechanisms. >> >> In June of 2016 the Internet Architecture Board organized a workshop on >> 'Internet of Things (IoT) Software Update (IOTSU)', which took place at >> Trinity College in Dublin, Ireland.  The main goal of the workshop was >> to foster a discussion on requirements, challenges, and solutions for >> bringing software and firmware updates to IoT devices.  This workshop >> also made clear that there is a lack of regulatory requirements, which >> contributes to challenges associated with misaligned incentives.  It is >> nevertheless seen as important to create standard building blocks that >> help interested parties implement and deploy a solid firmware update >> mechanism. >> >> In particular this group aims to publish three documents, namely: >>  *  An IoT firmware update architecture that includes a description of >>     the involved entities, security threats, and assumptions. >>  *  The manifest format. >>  *  A revision to RFC 4108 that reflects the current best practices. >> >> This group will use draft-moran-fud-architecture as a starting point for >> discussion of the "Architecture" document. >> >> This group will use draft-moran-fud-manifest as a starting point for >> discussion of the "Manifest Format" specification. >> >> This group does not aim to create a standard for a generic software >> update mechanism for use by rich operating systems, like Linux, but >> instead this group will focus on software development practices in the >> embedded industry.  "Software update solutions that target updating >> software other than the firmware binary (e.g. updating scripts) are >> also out of scope. >> >> This group will aim to develop a close relationship with silicon vendors >> and OEMs that develop IoT operating systems. >> >> >> Milestones: >> >> Dec 2017     Submit RFC 4108bis document as WG item. >> >> Dec 2017     Submit "Architecture" document as WG item. >> >> Dec 2017     Submit "Manifest Format" specification as WG item. >> >> Jul 2018     Submit "Architecture" to the IESG for publication as an >>             Informational RFC. >> >> Nov 2018     Submit RFC 4108bis document to the IESG for publication as >>             a Proposed Standard. >> >> Nov 2018     Submit "Manifest Format" to the IESG for publication as >>             a Proposed Standard. >> >> >> Additional calendar items: >> >> Mar 2018     Release initial version of the manifest creation tools as >>             open source. >> >> Apr 2018     Release first version of manifest test tools as open >>             source. >> >> Jun 2018     Release first IoT OS implementation of firmware update >>             mechanisms as open source. >> >> _______________________________________________ >> Fud mailing list >> Fud@ietf.org >> https://www.ietf.org/mailman/listinfo/fud >> > > > _______________________________________________ > Fud mailing list > Fud@ietf.org > https://www.ietf.org/mailman/listinfo/fud > From nobody Mon Oct 9 01:49:22 2017 Return-Path: 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 3B06C134DB4 for ; Mon, 9 Oct 2017 01:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=unavailable 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 BznOUCxBeA_Q for ; Mon, 9 Oct 2017 01:49:19 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 DB737134D33 for ; Mon, 9 Oct 2017 01:41:02 -0700 (PDT) Received: from [192.168.91.203] ([80.92.122.248]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LmJsk-1dRrsQ136A-00a0Ps; Mon, 09 Oct 2017 10:40:24 +0200 To: Jim Schaad , fud@ietf.org References: <5D8BA40A-0A70-44BC-B136-6A8946F4A80B@vigilsec.com> <021201d33d4f$8af662b0$a0e32810$@augustcellars.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <977c55f1-c4aa-3edc-e3e9-0142eec1c783@gmx.net> Date: Mon, 9 Oct 2017 10:40:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <021201d33d4f$8af662b0$a0e32810$@augustcellars.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:B3DnE1atORRi0Nn7skqEVtdu6TQptfLbkWM9OEnYBURvWz9SDbY LSMiwG3uF8hZqfOHVVmE3hZj5+GaHXM8rxD7TKH88w7W4bSM+9KJaL5tUHoSMvamW6HF8Fx BNcHb11qTjZ+R6l7yK/c5Matryigd9cmnyXrQ/fl8rc2D+T1zaFp0FAsRyCIpgXJvX05EAq /4gE/PouIezsUtLvNe3ow== X-UI-Out-Filterresults: notjunk:1;V01:K0:e+T1q6Elsqc=:pS1kqLy0FIi831VLlV5xbF XoudUH3TZeLEWTite6NluH0ApFLMZSx1T+GL4znmMZGU6nxUwMaeWaq01Il7XTVAg8YTBUpzY iw3YhOzfS0jZxXroOi/d+Elekrf2G8YrMPRgcvQkrfA39zVDfsQep3tWJUVycdTiuLD3epbr3 l1xcfx5G2g7uwUAyK1/8bq1y6PEzUj+gyTX0jOSPCsvQFcyna88BwFv7wNK7jUVoj7vvglxJs i7E9rd0xwWtLEr6M/74q8Z0smJ9QaPaDkb4A8tCYZQ99KYDU/1E1XCNF2V+nMG5cu6TdgSyQL 56YTaWcn/d7AzqXjRVYUKYrShjC09I2KPMH5XsLHU+DIolbSdKO586/AqOL+p4v/Zo8Jtusrq 33pqPU6lck7eIeXbOHd2HbRYW3HVNpBTdmP+oUlrVWMEdosGdVbVwU2pUnYSN4VzkNdmeQmV5 aznW8f6Ao3Hd1Tn+eLcwpKLKMKsMXzswhXqJKoz6h3g1tnx5lQbRYdSrJ5V0lgpOJPoTEDzRl 48CG57QxnLRTxzzQ+5iBx70X2U51QCYAxEd5l5bwzAH8s6nvjzTCKnjlTMmpI++sr706VCo9n LWzPW2Xus/B4VXtPa3Rz7D8Ls3POlUZ+6ymmbo0NHfebdfYoGHr0qh1z03d21mM/1OFHGwPQW h286Czrgen7t01BLYpE3yT4OpHvI8RHEz8H7j+IYoA8xrChZE0i3OAYZE50x7QO1YVlxJQZwY EWkrtk8090iuOzp9qWJDOiCyNuZxzNgP1NZMCclEFxshhUe34ZpNk3LHG63ys1edAadFSJNdO X/7I0E+5J2fwHcCn5kRg+omWZabJJOllQ6rRmH/evvPyr6MueM= Archived-At: Subject: Re: [Fud] A few questions / observations X-BeenThere: fud@ietf.org 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: Mon, 09 Oct 2017 08:49:21 -0000 Hi Jim, let me respond to this issue: On 10/04/2017 10:29 PM, Jim Schaad wrote: > Many of the people that I have talked to are looking at using either raw > public keys or pre-shared keys as the authentication mode for doing > TLS.  This means that the need for any ASN.1 decoding goes away from TLS > and the DER encoder would not be needed on the end product.  I think > this might be a YMMV statement. I guess it depends who you talk to. As you know, I am co-author of the TLS PSK and the TLS raw public key mechanism and as such I had obviously expected (or was hoping for) a widespread adoption of those mechanisms since they provide much better performance on paper. Since we always hear these stories about limitations of these IoT devices we obviously buy into these stories. However, our experience at ARM was a bit different. Those companies who cared about IoT security tend to be rather conservative and once they decide to go for the full-blown IoT solution (which includes a device management solution with firmware updates) they want to go for a certificate based approach. Of course, there is more overhead but often there are other factors that play a role in the decision making. For example, many of these companies are interested in reusing their existing infrastructure and processes. This might also explain why there is suddenly interest in standardizing the EST over CoAP-based certificate management protocol in ACE. Hence, I believe there is a disconnect between the " optimize like hell" and the "I need to deploy something I am familiar with" approaches. Ciao Hannes From nobody Mon Oct 9 08:53:46 2017 Return-Path: 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 2A5D5134EDA for ; Mon, 9 Oct 2017 08:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 QX3WOITYUdEe for ; Mon, 9 Oct 2017 08:53:39 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (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 16CBA134E7A for ; Mon, 9 Oct 2017 08:52:16 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id n14so12271661pfh.8 for ; Mon, 09 Oct 2017 08:52:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=qTn7EqoQAmJ0dpvEgZ23qAcm5rbdl5hNbwarvvoR4k4=; b=SIQY82Sx0QVAxBiHuqXDzm1K9rD2c0lmeu9sbOUBtHFrdePA6IM3/i+T9iEOYNeCjn 0gVemt33nZTDecKqZDGoO3/Gugyi5F5m/VPIqiyYlcaWQ/yemFmj7Vb0hcWSths9ENoU pXTfTebqVZErt/QprtrONlOnKzPFxRFaF8b6KM8ZH+uTyHVrSFeEME6Yw8J3SC2qw9pV h5meQpYrjW3xVqBKr9rII0ns5yAY3HdIndZEKAhyMSLYFuRIh64o7HV81am1mB3wMcCr rxNFyphjYvU+dS4quyWuUhxpH/FvPugQzvinLBRlXexs1cPGX5IglfX8enyvb5SZffte Zibw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=qTn7EqoQAmJ0dpvEgZ23qAcm5rbdl5hNbwarvvoR4k4=; b=GgW8rAUxz382mav2Adl1uS6hh249q1/yzvYtnWMdvHMh+8jfAReH9FLSKXt31jKAvb tnZSWSXtckaH/ITMKb8CG2YP7cg/UZt8vPG/IsxEQHumFmbXnACzZbs4G26hDbhB6yvq uiBdbWiCEzpSOEPMaqwCwHTir4Sz+vvvo9pnzKp8MI+GpOXmhGJXIPLKdn1GrS6mUXb9 8baio66rJQeI/9hitsUfFB+cQ1Z57NQ82F8yHeDK8wtYo+EwPA7l3cBd2TlNSysQf44E rnVqtLsN//fUR85OsbKoeK7ks9wtTDLI6Y35wTjx1hJiQgauHkIg/BOjT3smZhcpngBe hvhA== X-Gm-Message-State: AMCzsaVTD6hWETsHenQpHiMxr6RGaD/+0M1NKzKArwH10Odiv/sVGAah COxR+UP+eGVlpFjO2sWOleqPUJAf6nE0cTbdVR0= X-Google-Smtp-Source: AOwi7QCjMGx5Okq+5SgOxjMHj3ilHbEqZx5sl1DWqtkjQijun0sXt+aDNmWfbFvxF2fJNnqSNnwGQmlzVJaahzmkDTw= X-Received: by 10.99.113.92 with SMTP id b28mr9737657pgn.42.1507564335655; Mon, 09 Oct 2017 08:52:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.151.131 with HTTP; Mon, 9 Oct 2017 08:51:35 -0700 (PDT) From: Kathleen Moriarty Date: Mon, 9 Oct 2017 11:51:35 -0400 Message-ID: To: fud@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Fud] BoF approved X-BeenThere: fud@ietf.org 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: Mon, 09 Oct 2017 15:53:45 -0000 Hello, Thank you all for your hard work on the charter and milestones. FUD has been approved for a BoF in Singapore, so a room is reserved and it will be on the schedule. Nice job! -- Best regards, Kathleen From nobody Mon Oct 9 09:32:31 2017 Return-Path: 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 44F511346AA for ; Mon, 9 Oct 2017 09:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 V1mtQ5rIBeWM for ; Mon, 9 Oct 2017 09:32:29 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (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 E6227133205 for ; Mon, 9 Oct 2017 09:32:28 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id p87so5237012pfj.3 for ; Mon, 09 Oct 2017 09:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=71MTKYjo8Kh3rgHyPgBXf129stPLpOAxaPWv9wpHjx0=; b=oEoliL5R/BUGj0+/ObcT7XcO4wPaLR3gdIYLEfT/2HvKtw0zEYX+P1yvVFINHUWVHv inZwVz3NcQsUFv6+6YDo6Je6a9T2ZEuOEDenys2UM4Pq8/VqMtCJE4OI77XmCWwIDxmU kFmyil2NSzt2+N2rBIdzMInG73k/EMrJjO050Nef60alldHDB6QA1//6n2Vsaph9cOF7 qBZOjlDGtW+usYNohDp2kSz3ju7NJkGaP1FmqjlSZmVn/ipSgRbbu+BCLUEQNa6bT0bM 0EYA5wTRZtjBG3pt1mRO3TXC+bGEqhxSNGdxdn3uGz4HKmsrBQQdD9+cLPQ/H0HOvc1I JpMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=71MTKYjo8Kh3rgHyPgBXf129stPLpOAxaPWv9wpHjx0=; b=eTabXKwRXMVbOWe6JIsDciHJYMGaCsSdHS7reloWBUyTzWgH9YslHY+4+Zye9zflYu e4sQzxd6neeMKuNmsdOH5Lmwy4vxcWhxdjf6jJ6wud7Hszmvb6KFMpvGWYrlnvVLCVAr 7H8hRsT8rkUfF5pLbpIsNKNLFEhywi5sIpYYLZTsuHhRZzY6DR4taRQc3u0RMbCkAzBM ZLLpSz7uFxBzzlP/O8CC5iKZcjq6Rbnf2mmgtA/wLOi/oZKbwjKGxPAO0h9hjlw8VCKJ vwD5KyvyrBFEa8Ou8e0WSVPRnhVRhGJbZ74fsZ7kSj2aensCmUxPTr8Z3awBxLAloH/q ZqkA== X-Gm-Message-State: AMCzsaUN5j35vL0sSESrSlU9En4nR/tb8au2POdzdd1HeDX1W1WeGxOS 9L44KOzuHdho2TM+HvCaxFPmnBAvnoK7qXxzk1TjHA== X-Google-Smtp-Source: AOwi7QCTh+TNpmMzs0qserDAP8hDcXyKv4e25IoMhRn5yIRUXHlrbP7BLGW3d+R3OVwDzaHDJl4n5f8DXqdLJJT1HhY= X-Received: by 10.101.91.193 with SMTP id o1mr9471517pgr.75.1507566748409; Mon, 09 Oct 2017 09:32:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.151.131 with HTTP; Mon, 9 Oct 2017 09:31:47 -0700 (PDT) In-Reply-To: References: From: Kathleen Moriarty Date: Mon, 9 Oct 2017 12:31:47 -0400 Message-ID: To: fud@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Fud] BoF approved X-BeenThere: fud@ietf.org 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: Mon, 09 Oct 2017 16:32:30 -0000 A question came to me to know when the BoF will take place. The agenda has not been published yet, so I don't have the exact time, but it will be during the IETF week in November (11-17). https://ietf.org/meeting/100/index.html Best regards, Kathleen On Mon, Oct 9, 2017 at 11:51 AM, Kathleen Moriarty wrote: > Hello, > > Thank you all for your hard work on the charter and milestones. FUD > has been approved for a BoF in Singapore, so a room is reserved and it > will be on the schedule. > > Nice job! > > -- > > Best regards, > Kathleen -- Best regards, Kathleen From nobody Mon Oct 9 14:48:11 2017 Return-Path: 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 E83BB13293A for ; Mon, 9 Oct 2017 14:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 cfytmprBzkbB for ; Mon, 9 Oct 2017 14:48:08 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99821132195 for ; Mon, 9 Oct 2017 14:48:08 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D93EF200A1; Mon, 9 Oct 2017 17:53:50 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9EF3E81949; Mon, 9 Oct 2017 17:48:07 -0400 (EDT) From: Michael Richardson To: Kathleen Moriarty cc: fud@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Fud] BoF approved X-BeenThere: fud@ietf.org 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: Mon, 09 Oct 2017 21:48:10 -0000 --=-=-= Content-Type: text/plain Kathleen Moriarty wrote: > Thank you all for your hard work on the charter and milestones. FUD > has been approved for a BoF in Singapore, so a room is reserved and it > will be on the schedule. And is FUD still the working name? Who are the BOF chairs? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlnb7pcACgkQgItw+93Q 3WXeuAf/Z53shbC8PDq1sC6ZhWxwALzmd+qtlgp0YGoOA0095R8kNYqkbwz9Dxgu pNw/Vo9gmcKefRaHBAAogUJPIKgHEnBq0/mAsTF8GqiLOFY/eeIgE6PgiDS0zBLB guKEjV8GLlKg7tD8M5Shs3AH4g1PtznmPuK1nkkMzh9F1WXIybbKPIfxh/0mrwPa d+QDCoyZSxndrBSipgYDj0M5RQapgP8SkkHJo19+yQoxyxIOwpafsD+L7HQsezRC Hei51KQ3KjAatzZCKR4UCCG1RGtK0Mm5gzl105trn+GTIn9umw2fU8SA8L4vr2gu 35qe/HnP9/Yvlx9yVpv6cadB/BS2Lw== =q8TZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 9 14:58:37 2017 Return-Path: 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 32577132193 for ; Mon, 9 Oct 2017 14:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com 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 hDAkmgeexoxb for ; Mon, 9 Oct 2017 14:58:33 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961DC120720 for ; Mon, 9 Oct 2017 14:58:33 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1507586260; h=from:subject:to:date:message-id; bh=qCcZpbSo/R+rPJmiSiQi4W0b7lEfRwaLszd7sw42Yz8=; b=TmhxXchYP98NVj0XCwdzMy6McR0SBXBq9pet583mK8SAQ1PSjmnBEJlQHLxdeD/Obf3i/+Lb+v2 xUEwnJp/6m7wNFzDRQXLpDGj/hiu6fq7iBxfcNPUH/ChKWgyKJ9QZRWjmVz7ComZqrCHTu1YAk8f6 Fis0xKLhBMDGmf988RtxnCXOLWNxjSDADV/OYJoJfI7sb7j/NCW7jhjMflFcAQYNFu1VfhX9LQFvo 6lx7czVS6EoVlnSraIS3kXLY+yEijoiky6NWJ9oj6ssSKvWJOWefJl4gPiRq4CyGE8SeAqcNlzBi1 3aH3KziRkoqQh+JLxoIrqB1LmQiqAyq0vgGA== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 9 Oct 2017 14:57:40 -0700 Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 9 Oct 2017 14:57:16 -0700 From: Jim Schaad To: 'Hannes Tschofenig' , References: <5D8BA40A-0A70-44BC-B136-6A8946F4A80B@vigilsec.com> <021201d33d4f$8af662b0$a0e32810$@augustcellars.com> <977c55f1-c4aa-3edc-e3e9-0142eec1c783@gmx.net> In-Reply-To: <977c55f1-c4aa-3edc-e3e9-0142eec1c783@gmx.net> Date: Mon, 9 Oct 2017 14:58:03 -0700 Message-ID: <009201d34149$b013ebf0$103bc3d0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFIzdx4IdoVPeqc3QieDdoEAc8QRQI5vojWAvKo47ECCUOxa6O3Sh8g X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [Fud] A few questions / observations X-BeenThere: fud@ietf.org 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: Mon, 09 Oct 2017 21:58:35 -0000 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Monday, October 9, 2017 1:40 AM > To: Jim Schaad ; fud@ietf.org > Subject: Re: [Fud] A few questions / observations >=20 > Hi Jim, >=20 > let me respond to this issue: >=20 > On 10/04/2017 10:29 PM, Jim Schaad wrote: > > Many of the people that I have talked to are looking at using either > > raw public keys or pre-shared keys as the authentication mode for > > doing TLS. This means that the need for any ASN.1 decoding goes = away > > from TLS and the DER encoder would not be needed on the end product. > > I think this might be a YMMV statement. >=20 > I guess it depends who you talk to. I completely agree on that. It might be a bit higher after the OAuth = stuff gets deployed, I don't know Jim >=20 > As you know, I am co-author of the TLS PSK and the TLS raw public key > mechanism and as such I had obviously expected (or was hoping for) a > widespread adoption of those mechanisms since they provide much better > performance on paper. Since we always hear these stories about = limitations > of these IoT devices we obviously buy into these stories. >=20 > However, our experience at ARM was a bit different. Those companies = who > cared about IoT security tend to be rather conservative and once they = decide > to go for the full-blown IoT solution (which includes a device = management > solution with firmware updates) they want to go for a certificate = based > approach. Of course, there is more overhead but often there are other > factors that play a role in the decision making. For example, many of = these > companies are interested in reusing their existing infrastructure and > processes. This might also explain why there is suddenly interest in > standardizing the EST over CoAP-based certificate management protocol = in > ACE. >=20 > Hence, I believe there is a disconnect between the " optimize like = hell" > and the "I need to deploy something I am familiar with" approaches. >=20 > Ciao > Hannes From nobody Mon Oct 9 18:26:05 2017 Return-Path: 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 525C9133207 for ; Mon, 9 Oct 2017 18:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9iB08bEYbcwo for ; Mon, 9 Oct 2017 18:26:03 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (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 F0A16133073 for ; Mon, 9 Oct 2017 18:26:02 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id 17so7202119pfn.12 for ; Mon, 09 Oct 2017 18:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SVF9ja1mPozL6h/1+3ZKsmYr90KNuXDKutlSkNUUXnY=; b=SN04KOKuVPx00ujtKXslZlhgr/nbWt61IKvtXFc0oD8j/1QwH/lbEjB69STSxxu4hQ AH6rkBzkbGVpYL0IYKzpFff96wVj4LGTXw570+cAakNH0Do08ILzbZdAuRO5IgYhjIfd NCYcxUDaDWwgmXYzTtLvJgLDxMW+RQDQ1K5RH/ZUSMBadJTArzetuM6uMAy0WK4LSU2/ kAZztPEgCfM8iHTASCiE7MayRhu5Ndw5mlq/bK2j4bpVy9DcnICnxd4tEKi864e/40CX DZrYOwYLQJFQvaAQuiot3JpnnihmT7CJV3JBqzltqM+eVTzFmtadtTN7xOJUNTxJc2LS C3Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SVF9ja1mPozL6h/1+3ZKsmYr90KNuXDKutlSkNUUXnY=; b=MLCykOAte+YT/0FxawsfA34wa6GXMwf/a5Qk4hcNYMcTn7pZft5sfvgRXNS7MCEvf+ ZDA2JXovmDYORAl2iY3ZRi9agTFw9Zq9HqD3sk6gEVSAQ0favFNurz7m9Jzl7loGKgH8 tczZolTibVrq7p4jTCLKv8ikJ255eHXPZS+Si+65hX6FgzAGmZyLFGwXBKyMYmIO7kLO iqeK6S06kgT0lqP0WmoWgMMFcjfKk1KLO32vpuiu8S0wc57Hj1MEM7mWoPSOmQcrb7pA 47KNWfA0V6YZWEwggr8ZxTMjuc4pmHy/c1f1/7ZEsA/XJ7jBInd6WtUSdmffXHo/jbBE D6Zg== X-Gm-Message-State: AMCzsaXD67Y7aZXTCobADVcbQHchYrhytcKdM7onompFE86bKbERQ7Hp lU5YfNNoK1ZCPGb6clqs/d3MOERdNbi5UJ8J1hw= X-Google-Smtp-Source: AOwi7QCY3ofAvVRv1MDTfA+I2e+UOkeOD2GQ9eSqFnnMY3DbDMC5a8g2U7t2VcnSjCMcgR6K9fUkeaN3zxm2PHJwLGY= X-Received: by 10.99.113.92 with SMTP id b28mr10861141pgn.42.1507598762641; Mon, 09 Oct 2017 18:26:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.151.131 with HTTP; Mon, 9 Oct 2017 18:25:22 -0700 (PDT) In-Reply-To: <12088.1507585687@obiwan.sandelman.ca> References: <12088.1507585687@obiwan.sandelman.ca> From: Kathleen Moriarty Date: Mon, 9 Oct 2017 21:25:22 -0400 Message-ID: To: Michael Richardson Cc: fud@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Fud] BoF approved X-BeenThere: fud@ietf.org 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: Tue, 10 Oct 2017 01:26:04 -0000 Hi Michael, The BoF chairs were announced previously, they are David Waltermire and Russ Housley. This is likely to change once this becomes a WG. There seems to be agreement on changing the name. I am fine with SUIT, do the list participants have a strong feeling for this or another acronym? Thanks, Kathleen On Mon, Oct 9, 2017 at 5:48 PM, Michael Richardson wrote: > > Kathleen Moriarty wrote: > > Thank you all for your hard work on the charter and milestones. FUD > > has been approved for a BoF in Singapore, so a room is reserved and it > > will be on the schedule. > > And is FUD still the working name? > Who are the BOF chairs? > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > -- Best regards, Kathleen From nobody Mon Oct 9 18:29:36 2017 Return-Path: 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 B0EFA133207 for ; Mon, 9 Oct 2017 18:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=phosphorus-io.20150623.gappssmtp.com 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 DaibFjbHSfG6 for ; Mon, 9 Oct 2017 18:29:07 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 679321320D8 for ; Mon, 9 Oct 2017 18:29:07 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id f8so11986249qta.5 for ; Mon, 09 Oct 2017 18:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=phosphorus-io.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=u3xO2uqYg3oLkxeZnOf7T2fbqsc8GoYTGK6kqTqlroM=; b=ykpo9f5ikdGKp7jUUa4kxjkuXDNUOaKjKi+LIWXh7x+Vax0N1Iku5xw7fq2CMzBqHB v3NXezYSMQr3lDYHq4z/v2K0afqq3N3vdkhRQMfJrx94Kxw7ngRo+eZ3miZ8lOAHwWJU SrKv+9vqWlxZDRxNv6XHv2NvnRmndMj6cHaCoA9CBlBCIqDwW9bQmZxmnPmQuTRrehZi zt7QofDftSC1517yuCWp766QjcneZFJgczRvW8KMQLCca+oSVdXQwHZwtY4pz0me3ybd 1JLHGcZCBvBoKfHXjgFmCiJsjJe+GxJon3Z1i5JglYyL1uegrBJEhNiZbqVet0XmJ6X/ +XBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=u3xO2uqYg3oLkxeZnOf7T2fbqsc8GoYTGK6kqTqlroM=; b=hXXFcLxP8AnL5ItUZBhjahde+ScjcCtIoHAvuvDPD4+bXc+pxphXSidAEJ4SKUIyu2 vlL/vLfIK/B6DZGBjTR8hoFTcDCV/I7O+FlTgxLlrl66s/0//q8b3pW3TfrNhNGKGuq7 JRVT3tZNP3AySk/YKFajl8y21CoxB+cI4eIgHKojTrChzg+nIzDowctd+6V0U/ZEbCgp wgJNEvhkBNkXaHDS7rRy8mBpw+2qiT+2i+3g6NrTdjEz37jakpcGOFdwa5fBIyj8XRRi ugA3Z/+78OoUmwIdGyzMZ4mzw82qUILHiMUMn/AL5hM4sUcC/qUWpNS4KvSRMomjlTZz 0VFQ== X-Gm-Message-State: AMCzsaUe+uat/ZSaJb5JVTPGT+ptl4UlDK6Q2Mg8ncumnOY0YT40wp7e dqsr9RSF+l8p2ImHKfyOC/swXw== X-Google-Smtp-Source: AOwi7QC+PPckbAMM8woAvutk/bx9Z6zLFtCpanNmemOwPL4+cFJ4U7HyJ9sa3ZD3Whe67R4Ros4kwQ== X-Received: by 10.37.92.132 with SMTP id q126mr1092218ybb.253.1507598946579; Mon, 09 Oct 2017 18:29:06 -0700 (PDT) Received: from [192.168.0.38] ([64.191.55.71]) by smtp.gmail.com with ESMTPSA id v130sm3574248ywc.66.2017.10.09.18.29.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Oct 2017 18:29:05 -0700 (PDT) From: Chris Rouland Message-Id: <599697BD-8C81-45E8-A6A7-AF74A06E17F6@phosphorus.io> Content-Type: multipart/alternative; boundary="Apple-Mail=_650B30A5-60CB-4CB1-876B-985C3DFA3682" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 9 Oct 2017 21:29:04 -0400 In-Reply-To: Cc: Michael Richardson , fud@ietf.org To: Kathleen Moriarty References: <12088.1507585687@obiwan.sandelman.ca> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Fud] BoF approved X-BeenThere: fud@ietf.org 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: Tue, 10 Oct 2017 01:29:36 -0000 --Apple-Mail=_650B30A5-60CB-4CB1-876B-985C3DFA3682 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I agree with SUIT -Chris > On Oct 9, 2017, at 9:25 PM, Kathleen Moriarty = wrote: >=20 > Hi Michael, >=20 > The BoF chairs were announced previously, they are David Waltermire > and Russ Housley. This is likely to change once this becomes a WG. >=20 > There seems to be agreement on changing the name. I am fine with > SUIT, do the list participants have a strong feeling for this or > another acronym? >=20 > Thanks, > Kathleen >=20 > On Mon, Oct 9, 2017 at 5:48 PM, Michael Richardson > wrote: >>=20 >> Kathleen Moriarty wrote: >>> Thank you all for your hard work on the charter and milestones. FUD >>> has been approved for a BoF in Singapore, so a room is reserved and = it >>> will be on the schedule. >>=20 >> And is FUD still the working name? >> Who are the BOF chairs? >>=20 >> -- >> Michael Richardson , Sandelman Software Works >> -=3D IPv6 IoT consulting =3D- >>=20 >>=20 >>=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen >=20 > _______________________________________________ > Fud mailing list > Fud@ietf.org > https://www.ietf.org/mailman/listinfo/fud --Apple-Mail=_650B30A5-60CB-4CB1-876B-985C3DFA3682 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I agree with SUIT

-Chris



On Oct 9, 2017, at 9:25 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Hi = Michael,

The BoF chairs were announced = previously, they are David Waltermire
and Russ Housley. =  This is likely to change once this becomes a WG.

There seems to be agreement on changing the name.  I am = fine with
SUIT, do the list participants have a strong = feeling for this or
another acronym?

Thanks,
Kathleen

On = Mon, Oct 9, 2017 at 5:48 PM, Michael Richardson
<mcr+ietf@sandelman.ca> wrote:

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
Thank you all for your = hard work on the charter and milestones.  FUD
has = been approved for a BoF in Singapore, so a room is reserved and it
will be on the schedule.

And is FUD still the working name?
Who are the = BOF chairs?

--
Michael = Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
-=3D IPv6 IoT consulting =3D-





--

Best regards,
Kathleen

_______________________________________________
Fud mailing list
Fud@ietf.org
https://www.ietf.org/mailman/listinfo/fud

= --Apple-Mail=_650B30A5-60CB-4CB1-876B-985C3DFA3682-- From nobody Mon Oct 9 18:54:27 2017 Return-Path: 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 83907132D22 for ; Mon, 9 Oct 2017 18:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 tQ09xFqseOZF for ; Mon, 9 Oct 2017 18:54:23 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD212126B7E for ; Mon, 9 Oct 2017 18:54:23 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A1442E00A; Mon, 9 Oct 2017 22:00:06 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D5A898071B; Mon, 9 Oct 2017 21:54:22 -0400 (EDT) From: Michael Richardson To: Kathleen Moriarty cc: fud@ietf.org In-Reply-To: References: <12088.1507585687@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Fud] BoF approved X-BeenThere: fud@ietf.org 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: Tue, 10 Oct 2017 01:54:25 -0000 --=-=-= Content-Type: text/plain Kathleen Moriarty wrote: > The BoF chairs were announced previously, they are David Waltermire > and Russ Housley. This is likely to change once this becomes a WG. > There seems to be agreement on changing the name. I am fine with > SUIT, do the list participants have a strong feeling for this or > another acronym? FUD is a great humourous first name, but not a good long term one. I like SUIT a lot. I'd rather it was renamed before the BOF so as to remove that bikeshed from the mic line. > On Mon, Oct 9, 2017 at 5:48 PM, Michael Richardson > wrote: >> >> Kathleen Moriarty wrote: >> > Thank you all for your hard work on the charter and milestones. FUD >> > has been approved for a BoF in Singapore, so a room is reserved and it >> > will be on the schedule. >> >> And is FUD still the working name? >> Who are the BOF chairs? >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> > -- > Best regards, > Kathleen -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlncKE4ACgkQgItw+93Q 3WUC0wf/alIoJw5Qv1ub0CUBC4oMOxJxYe1EBvPjJhXSOH2xUhlQHRe+ag+W+fIR +jVRnWrWt0RaMTeU51Vm1QTa4OltI5q9RLvZ8D2FpMs5F7Po9aAyGLdIG/LlfJjD sA1SMSf+k1sT/muzIomHfgJg4mmdWKfpGzeoxcfx1exv2hPrYw8g/UcfsewCTMJT pRFRMXGoS9Sk5YLmlVPqMKxi4XUDQsq0ITlTFSL84rVG3cz7IvyzcpSPzchhqe+1 NY5GDIQxImkmWUTg2FN/R8TJMCSb8vWCXNU/OLfLlQNnQzFmdSsP2Zv+b2ST2t+r 3aIvTEpMsdzI2rHNx/JpxnySzc5MwA== =z18z -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 9 20:00:47 2017 Return-Path: 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 C5AD9134772 for ; Mon, 9 Oct 2017 20:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Vg6KBr87v-6k for ; Mon, 9 Oct 2017 20:00:44 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 220EE134686 for ; Mon, 9 Oct 2017 20:00:42 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id n61so19425230qte.10 for ; Mon, 09 Oct 2017 20:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CllaV9kZTBEIj0g/R7sfuZBGYF4vrXpXrvCMbsUzyOo=; b=sn3jZ11c5a7paa4/L6ncso8tLY3kjB6l5XGV4N2ksRE9n8C6V6Rb/D10q5y1sNwJVD Hj2SCZELTBNZiirJrbYCNgPBxiLS3neHiqILrx+n30+gqmIVFUJzzculvrslnNrqgRCJ UNyT5U0x/cGqBnQKe0vZVYI5NRUwQgBC1HJwqf/x63bJJSPMacCE8ZNduDREk66UBI4T LDVBfevGUiPnU7GV2DS5pdRg9jF8lvrexA1PEAVBaJtpN1Ek9Had7Z9fUYnLlfeXKFiX SELCAavOcjjNUmx1L5MjYyYea4SJ8SQGtHP6edhGm+KVfJ4CghKyxCn+xHnqCAak2AzR O8QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CllaV9kZTBEIj0g/R7sfuZBGYF4vrXpXrvCMbsUzyOo=; b=aTqQHojZ4VKPxyjVYTkFcoKYW/kOBg5V9EkQ8umHgh/tRF7nB1Q+DHJDVsAFWqb89/ OGXY1m+DPuVFgMXIaKiKfPbsiwW6P9ee7jpuiud3qjaI2OY/RFeVMRVt07mXvGW6yXIU NRwgCwbpFkiMm2pJ7zcFqdrZ3YZrpSksceeOpomcUH6ePg5lDrAbn2PhiOFnjVgyjavI KtHgAtrScTOCA/3J9R21eIV6xgOQsW927gsKmGauQGFg11m4YsV/LHdXM+7juRKNEKsC 8Zv/eBSrj12NjRzGGJnZM3xaQ0CyxC/zty3G3fhEvNRgoI+/KLj9f/Yahs6GPK1b93RR SIuw== X-Gm-Message-State: AMCzsaXYxOhRTxqna8/4M19M2pPu+Hz41/DQNS4U4erzWaEdp01wJX1R okW/P8bIuap/FmN+uYcgirsAGrTd X-Google-Smtp-Source: AOwi7QC+rpG0g95pJ663hs3v4bY4kR6c4docIUae4xxxH5DaBpFm1ShWi3Ug27n5MvowqrK+osmvbA== X-Received: by 10.55.24.170 with SMTP id 42mr10983951qky.220.1507604440998; Mon, 09 Oct 2017 20:00:40 -0700 (PDT) Received: from [192.168.1.6] (209-6-124-204.s3530.c3-0.arl-ubr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id h19sm5971315qta.26.2017.10.09.20.00.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Oct 2017 20:00:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (14F89) In-Reply-To: <25499.1507600462@obiwan.sandelman.ca> Date: Mon, 9 Oct 2017 23:00:39 -0400 Cc: fud@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <12088.1507585687@obiwan.sandelman.ca> <25499.1507600462@obiwan.sandelman.ca> To: Michael Richardson Archived-At: Subject: Re: [Fud] BoF approved X-BeenThere: fud@ietf.org 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: Tue, 10 Oct 2017 03:00:46 -0000 Sent from my iPhone > On Oct 9, 2017, at 9:54 PM, Michael Richardson wro= te: >=20 >=20 > Kathleen Moriarty wrote: >> The BoF chairs were announced previously, they are David Waltermire >> and Russ Housley. This is likely to change once this becomes a WG. >=20 >> There seems to be agreement on changing the name. I am fine with >> SUIT, do the list participants have a strong feeling for this or >> another acronym? >=20 > FUD is a great humourous first name, but not a good long term one. > I like SUIT a lot. >=20 > I'd rather it was renamed before the BOF so as to remove that bikeshed fro= m > the mic line. Good point, it could be a colossal waste of time. I'd like to hear a bit mo= re from participants, I believe the chairs punted to me. Thanks, Kathleen=20 >=20 >> On Mon, Oct 9, 2017 at 5:48 PM, Michael Richardson >> wrote: >>>=20 >>> Kathleen Moriarty wrote: >>>> Thank you all for your hard work on the charter and milestones. FUD >>>> has been approved for a BoF in Singapore, so a room is reserved and it >>>> will be on the schedule. >>>=20 >>> And is FUD still the working name? >>> Who are the BOF chairs? >>>=20 >>> -- >>> Michael Richardson , Sandelman Software Works >>> -=3D IPv6 IoT consulting =3D- >>>=20 >>>=20 >>>=20 >=20 >=20 >=20 >> -- >=20 >> Best regards, >> Kathleen >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 From nobody Mon Oct 9 22:39:46 2017 Return-Path: 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 7A424132C2A for ; Mon, 9 Oct 2017 22:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVPcdu28wwfC for ; Mon, 9 Oct 2017 22:39:43 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5053E1332D5 for ; Mon, 9 Oct 2017 22:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v9A5dcP9029696; Tue, 10 Oct 2017 07:39:38 +0200 (CEST) Received: from sev.localdomain (unknown [212.98.163.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yB5XT5RKPzDKx5; Tue, 10 Oct 2017 07:39:37 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Tue, 10 Oct 2017 07:39:36 +0200 Cc: Michael Richardson , fud@ietf.org X-Mao-Original-Outgoing-Id: 529306775.330655-0aca6227046ce427d2a06ccf9b2d4818 Content-Transfer-Encoding: quoted-printable Message-Id: <410217DA-2E71-4A01-89A9-122DBA441D2B@tzi.org> References: <12088.1507585687@obiwan.sandelman.ca> <25499.1507600462@obiwan.sandelman.ca> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Fud] BoF approved X-BeenThere: fud@ietf.org 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: Tue, 10 Oct 2017 05:39:45 -0000 On Oct 10, 2017, at 05:00, Kathleen Moriarty = wrote: >=20 >> FUD is a great humourous first name, but not a good long term one. >> I like SUIT a lot. >>=20 >> I'd rather it was renamed before the BOF so as to remove that = bikeshed from >> the mic line. >=20 > Good point, it could be a colossal waste of time. I'd like to hear a = bit more from participants, I believe the chairs punted to me. Please rename. When we started the work on Improvements of DTLS for the IOT, we got = strong feedback from implementers that they wouldn=E2=80=99t be able to = get their organizations to do work on components that are labelled = IDIOT. So DICE it became. The same logic applies here. (And SUIT indeed is a good name =E2=80=94 I actually do like the fact = that it calls what used to be called =E2=80=9Cfirmware=E2=80=9D, = =E2=80=9Csoftware=E2=80=9D instead.) Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Oct 10 01:42:13 2017 Return-Path: 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 37DD9134AB9 for ; Tue, 10 Oct 2017 01:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmKemLaPGHvf for ; Tue, 10 Oct 2017 01:42:05 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 606AE134704 for ; Tue, 10 Oct 2017 01:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v9A8ffUu028274; Tue, 10 Oct 2017 10:41:41 +0200 (CEST) Received: from sev.localdomain (unknown [212.98.163.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yB9ZY2KnZzDL16; Tue, 10 Oct 2017 10:41:41 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <66e408f7-44b5-b1a3-a53b-82454b8260a4@gmx.net> Date: Tue, 10 Oct 2017 10:41:39 +0200 Cc: Russ Housley , "Fud@ietf.org" X-Mao-Original-Outgoing-Id: 529317698.836866-a20132724784cc4203c499da80c83c0b Content-Transfer-Encoding: quoted-printable Message-Id: <22E7B666-4035-401D-8A7C-C67FCA78E326@tzi.org> References: <578DD8B8-E786-4913-AE6A-65FFA29019AD@vigilsec.com> <66e408f7-44b5-b1a3-a53b-82454b8260a4@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Fud] Editorial Charter Update X-BeenThere: fud@ietf.org 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: Tue, 10 Oct 2017 08:42:12 -0000 On Oct 9, 2017, at 10:24, Hannes Tschofenig = wrote: >=20 > Hi Carsten >=20 > I had provided a response to your comment and asked whether it = clarifies > things. >=20 > I don't believe you have responded. Sorry, I=E2=80=99m way behind in my mail. > So far, I haven't heard you saying anything about what you would like = to > see done in this working group. I think the discussion has evolved towards focusing on data formats for = describing software update packages and their applicability in a secure = way. Being able for a set of managing entities (for the device owner, = for the device manufacturer, for authorized third parties) to properly = authorize the update of a (potentially low-resource) device with = firmware that is fresh, appropriate for the device and its = configuration, and appropriate for the usage situation that device is = in. > I would also like to know what you see > wrong with bug fixing and tweaking? Nothing is wrong with that if what is being fixed and tweaked is solving = the problem after finishing the fixing and tweaking. Not sure we are in = that position. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Oct 10 02:08:21 2017 Return-Path: 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 60CD2134B23 for ; Tue, 10 Oct 2017 02:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 3aOeCAqCIZlw for ; Tue, 10 Oct 2017 02:08:19 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 B9D97134B18 for ; Tue, 10 Oct 2017 02:08:18 -0700 (PDT) Received: from [192.168.91.203] ([80.92.122.248]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MTMzb-1dss4X0N4J-00SO08; Tue, 10 Oct 2017 11:08:06 +0200 To: Carsten Bormann Cc: "Fud@ietf.org" , Russ Housley References: <578DD8B8-E786-4913-AE6A-65FFA29019AD@vigilsec.com> <66e408f7-44b5-b1a3-a53b-82454b8260a4@gmx.net> <22E7B666-4035-401D-8A7C-C67FCA78E326@tzi.org> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <1397063d-b0b3-d7cf-4c0e-72cf18d20958@gmx.net> Date: Tue, 10 Oct 2017 11:08:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <22E7B666-4035-401D-8A7C-C67FCA78E326@tzi.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:noYN2huvTvDLKEhTMZ5opzrnTp6yCN50Hkm3JFaT/QMsmCK4I0l 0wXh8XfxzP7N4S9wkjTTn/lPgUCMKFPTO0eCGJYfNDFLIFXhj0OUBfOaY1Ujh3QGNc2B1f7 psG5M6/s1ekkP9tIZ8Njvju9qtdWpKeg0SG4c9nRMJ1+rXg8+f1h+V1zcqCAgG2jLKVTKoU 9fP9CptoZEQm7K2yZn0Gw== X-UI-Out-Filterresults: notjunk:1;V01:K0:cjRl9fUIMag=:0ACMxsQRdMOHgq1I4jmeSe 0GzVipru/R+bLmQHh5Km+Uj7GYu2mpc3q+OD5CcKNyxKDi2X9UkJWjF3PojcmgRCV43X6dh8P byHSBKbXrdOra66j7CTcLzB2hpQjMA+1jv+UM0Yw9TDmPxT5dDsJqfiBbgnAGL6aQdlhWupl0 zJd41ISD9NiI2A9MQMVI/CNtCgdhO8VUcJvh00Omwcs09GhmqAJLs9ZUOMgLMf1JLC0mxh56T u3PtY4c9BHprqTvF4comNvXYvkoiubyT60rNwCSDc1lPWH6txEhh72HfKa9UekqV223YICNbr dHeVet7RH3uDazwul2jS739OXukEZCdYxEAt6smybP/sJVVGBL2B7mfbgYiO7kXtTvTUF8BgT v6GpaQAlm+wKJ6seyGXqt8qK8M879D82CjxFMj+bboXhRVDbJEUJUg7HK+giE8SuVG3EL4pfi WMmSKBfz1vU2LhTdRby2DDTTwjHuvv9VjrksAF/EnbJTz2BpOTThZGqoxwm8MKMBoocMH+GY7 8uy7LQaYFkIhuIA3K2hSTbvvQY9KMWEVOybe5ZfUU1oQwHKQZ2x2bZJ2EIsPOWphxqx8ObSxw KtH4UsdrbBEPqgsf+oZ2fIzOIg2xbKTHG1F3pCKaZmbARe8PRW3oW6umwt+M3Fz1dLlOIr6Fb w4b7C663jMJ+kYwfqWWWBntXoDCzsbtmvLO8J/2B6YX0mSg/YcgKJZhzPXtmw/0OOqIM+1Wbp uP1Of7MWhv+WKFaOdhCfFRxEPjb9aeXRe0JB4kL9WQyN/lfjZFAzBf3XeXToiwJBGeZ0HUtlz T1/8LpMqJJai5txLL0VIOuleG7EF0phZmg3iF6FPDtIPeHyOPY= Archived-At: Subject: Re: [Fud] Editorial Charter Update X-BeenThere: fud@ietf.org 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: Tue, 10 Oct 2017 09:08:20 -0000 Hi Carsten, On 10/10/2017 10:41 AM, Carsten Bormann wrote: > I think the discussion has evolved towards focusing on data formats for describing software update packages and their applicability in a secure way. Being able for a set of managing entities (for the device owner, for the device manufacturer, for authorized third parties) to properly authorize the update of a (potentially low-resource) device with firmware that is fresh, appropriate for the device and its configuration, and appropriate for the usage situation that device is in. I wouldn't say it has evolved but it is now more clearly described. But if you like the current text then I am happy. Ciao Hannes From nobody Fri Oct 13 12:07:47 2017 Return-Path: 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 244361321A7 for ; Fri, 13 Oct 2017 12:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 TUKNqnF6uXE7 for ; Fri, 13 Oct 2017 12:07:45 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (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 1E7B8134215 for ; Fri, 13 Oct 2017 12:07:43 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id v78so1894553pgb.5 for ; Fri, 13 Oct 2017 12:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kMaJSQJw4kKbKUZQtq1Fj8dkpXsEG7xSwfewtF1Go9I=; b=lYoui3fUbE6JPFh/rAub5VF5lkRds8Lq48dEt9p3Vc7FNlmqItZfgX2ekcIp9G7XF3 2ogDhZXjP+/k8G8N4woKub54jm8URwqRucVlAREQccxxguLKpVJPDgl9eP2KLXLRokVc ddehKZAbf6VEaFRn3O/h8ZdA0k4+DDIVj1mTpd8dCNU/ordv/2rf0lCchsUHPHKGcfcz LoECMYexpS+LQArULv7AHZJ03WjRix9fbVfo7H+UyCKRdeKYwJun5l8df+PcPS2tQr/w XWIvugZ0JLIkKatdQkpXF25Svy+t+k7/wKWBL14UjmmjRx+x2MD4bByq5OjL6neSOXCX YekA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kMaJSQJw4kKbKUZQtq1Fj8dkpXsEG7xSwfewtF1Go9I=; b=CH2LWRM92UHFyGQeGjEpkY4iDr0Hzf9vDzfaGlypSpIXbBN8GN6ZasRr+qBQGmlwH2 5WzKoLx8Yu0QyGGUnXdKexAR3oYmwg6AAHkUEcPoKtsn1QWjrU80+Gj0QNK0CRjDcgww fmKwa8t9Yxni9vTHQ9FD1yGn1uVQCinSy25xpcr0qNo4WbVVN/tHvVQGfF1Lbccp1L9b yzjKTipXe17vhU/DZA3f/FC1yEgftX7KjdIwopSUAxY3XoE5jr+3/Im7+mLkw/eLHHKe fjEy3e0bWSyomuvpuemHxRxJrOZp/7IBHwZlmbVfbIPcc0kuKviirgmMtb2S5GIi696c t+3Q== X-Gm-Message-State: AMCzsaVYXOMK9Yj7cC3M0hJdPdBb7FTP60123kxfT0HUgEO1YTBqr5it csZzoQ/QznLgLs9OKQwBePoo01dQI4lMR5y/iFw= X-Google-Smtp-Source: AOwi7QDwaSmwNZW1SOVEIH6jJho/WXrknqh3NACVHN/vhe/9WZnv3DVcYlUJ4n4EHloq/Lg8RjWYG6qfIWuyrpiLRjw= X-Received: by 10.101.91.193 with SMTP id o1mr2042914pgr.75.1507921662736; Fri, 13 Oct 2017 12:07:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.194 with HTTP; Fri, 13 Oct 2017 12:07:02 -0700 (PDT) In-Reply-To: References: <12088.1507585687@obiwan.sandelman.ca> <25499.1507600462@obiwan.sandelman.ca> From: Kathleen Moriarty Date: Fri, 13 Oct 2017 15:07:02 -0400 Message-ID: To: Michael Richardson Cc: fud@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Fud] BoF approved X-BeenThere: fud@ietf.org 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: Fri, 13 Oct 2017 19:07:47 -0000 I haven't heard any reasons to keep FUD or objections to changing the name, so I'll start the process to do that. I will also ask if the mailing list can be set up under suit and the membership be transferred as it's easier to have the name of the WG match the mailing list. Best regards, Kathleen On Mon, Oct 9, 2017 at 11:00 PM, Kathleen Moriarty wrote: > > > Sent from my iPhone > >> On Oct 9, 2017, at 9:54 PM, Michael Richardson wrote: >> >> >> Kathleen Moriarty wrote: >>> The BoF chairs were announced previously, they are David Waltermire >>> and Russ Housley. This is likely to change once this becomes a WG. >> >>> There seems to be agreement on changing the name. I am fine with >>> SUIT, do the list participants have a strong feeling for this or >>> another acronym? >> >> FUD is a great humourous first name, but not a good long term one. >> I like SUIT a lot. >> >> I'd rather it was renamed before the BOF so as to remove that bikeshed from >> the mic line. > > Good point, it could be a colossal waste of time. I'd like to hear a bit more from participants, I believe the chairs punted to me. > > Thanks, > Kathleen >> >>> On Mon, Oct 9, 2017 at 5:48 PM, Michael Richardson >>> wrote: >>>> >>>> Kathleen Moriarty wrote: >>>>> Thank you all for your hard work on the charter and milestones. FUD >>>>> has been approved for a BoF in Singapore, so a room is reserved and it >>>>> will be on the schedule. >>>> >>>> And is FUD still the working name? >>>> Who are the BOF chairs? >>>> >>>> -- >>>> Michael Richardson , Sandelman Software Works >>>> -= IPv6 IoT consulting =- >>>> >>>> >>>> >> >> >> >>> -- >> >>> Best regards, >>> Kathleen >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> -- Best regards, Kathleen From nobody Fri Oct 13 12:17:22 2017 Return-Path: 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 EBC30132D49 for ; Fri, 13 Oct 2017 12:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 IoA65C1KnYTT for ; Fri, 13 Oct 2017 12:17:19 -0700 (PDT) Received: from mail-edgeKA27.fraunhofer.de (mail-edgeka27.fraunhofer.de [153.96.1.27]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B28B9132A89 for ; Fri, 13 Oct 2017 12:17:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2GoBABp299Z/xoBYJleGQEBAQEBAQEBAQEBBwEBAQEBg11naycHg3OZUYFLCSKIRY98CoIBgzoChD9CFQECAQEBAQEBAQNoKIUeAQUjDwEFNgsQCQIYAgImAgIhJhAGAQkDAQUCAQGKAgMUAQSOB51ngieFO4IFDYNvAQEBAQEFAQEBAQEBASGBDoIfggeBUYFqKwuBZoEOgl6FOoJhAQSRRoceiCQ8gQiBJo1DkFYFhy6NAIg+AgQGBQIZAYE5NSOBBwdTJl2HH3QBikUBgRABAQE X-IPAS-Result: A2GoBABp299Z/xoBYJleGQEBAQEBAQEBAQEBBwEBAQEBg11naycHg3OZUYFLCSKIRY98CoIBgzoChD9CFQECAQEBAQEBAQNoKIUeAQUjDwEFNgsQCQIYAgImAgIhJhAGAQkDAQUCAQGKAgMUAQSOB51ngieFO4IFDYNvAQEBAQEFAQEBAQEBASGBDoIfggeBUYFqKwuBZoEOgl6FOoJhAQSRRoceiCQ8gQiBJo1DkFYFhy6NAIg+AgQGBQIZAYE5NSOBBwdTJl2HH3QBikUBgRABAQE X-IronPort-AV: E=Sophos;i="5.43,368,1503352800"; d="scan'208";a="955701" Received: from mail-mtaka26.fraunhofer.de ([153.96.1.26]) by mail-edgeKA27.fraunhofer.de with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 13 Oct 2017 21:17:16 +0200 X-IronPort-AV: E=Sophos;i="5.43,368,1503352800"; d="scan'208";a="264639613" X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaka26.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Oct 2017 21:17:16 +0200 Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v9DJHEhc000699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Oct 2017 21:17:15 +0200 Received: from [192.168.16.50] (134.102.43.163) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 13 Oct 2017 21:17:09 +0200 To: Kathleen Moriarty , Michael Richardson CC: References: <12088.1507585687@obiwan.sandelman.ca> <25499.1507600462@obiwan.sandelman.ca> From: Henk Birkholz Message-ID: Date: Fri, 13 Oct 2017 21:17:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [134.102.43.163] Archived-At: Subject: Re: [Fud] BoF approved X-BeenThere: fud@ietf.org 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: Fri, 13 Oct 2017 19:17:22 -0000 To provide (admittedly late) some support: +1 for SUIT No objections. Viele Grüße, Henk On 10/13/2017 09:07 PM, Kathleen Moriarty wrote: > I haven't heard any reasons to keep FUD or objections to changing the > name, so I'll start the process to do that. I will also ask if the > mailing list can be set up under suit and the membership be > transferred as it's easier to have the name of the WG match the > mailing list. > > Best regards, > Kathleen > > On Mon, Oct 9, 2017 at 11:00 PM, Kathleen Moriarty > wrote: >> >> >> Sent from my iPhone >> >>> On Oct 9, 2017, at 9:54 PM, Michael Richardson wrote: >>> >>> >>> Kathleen Moriarty wrote: >>>> The BoF chairs were announced previously, they are David Waltermire >>>> and Russ Housley. This is likely to change once this becomes a WG. >>> >>>> There seems to be agreement on changing the name. I am fine with >>>> SUIT, do the list participants have a strong feeling for this or >>>> another acronym? >>> >>> FUD is a great humourous first name, but not a good long term one. >>> I like SUIT a lot. >>> >>> I'd rather it was renamed before the BOF so as to remove that bikeshed from >>> the mic line. >> >> Good point, it could be a colossal waste of time. I'd like to hear a bit more from participants, I believe the chairs punted to me. >> >> Thanks, >> Kathleen >>> >>>> On Mon, Oct 9, 2017 at 5:48 PM, Michael Richardson >>>> wrote: >>>>> >>>>> Kathleen Moriarty wrote: >>>>>> Thank you all for your hard work on the charter and milestones. FUD >>>>>> has been approved for a BoF in Singapore, so a room is reserved and it >>>>>> will be on the schedule. >>>>> >>>>> And is FUD still the working name? >>>>> Who are the BOF chairs? >>>>> >>>>> -- >>>>> Michael Richardson , Sandelman Software Works >>>>> -= IPv6 IoT consulting =- >>>>> >>>>> >>>>> >>> >>> >>> >>>> -- >>> >>>> Best regards, >>>> Kathleen >>> >>> -- >>> Michael Richardson , Sandelman Software Works >>> -= IPv6 IoT consulting =- >>> >>> >>> > > > From nobody Fri Oct 13 14:16:42 2017 Return-Path: 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 3311B132D8A for ; Fri, 13 Oct 2017 14:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 RMBa_ayrfS-t for ; Fri, 13 Oct 2017 14:16:38 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 B44621321B6 for ; Fri, 13 Oct 2017 14:16:38 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id x7so11339259pfa.1 for ; Fri, 13 Oct 2017 14:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=RFZCpepgN9sXQyzQPsLbhNkKiYmWa7j+QSyJIBNrFeU=; b=Eo3HsNncgbJ38OQvRUtToiUmXoTontvNwu+pN45Q3CEDKJE29yRf5D3mfOBjy4qbXS haKoxtPEP/QmHfQmh5s5TrkIWg9XjbNqmmpmh7xjYdurbz+ABmJMoAw75ax47AQlWiOw KC+ktNFn7qu5FqTk3krmAPc3il4y/2lKp2czBAzOTAhwkMPul1R1RKMPaMmww5ipIebW jjb2Sv10AYSuHhfjfJeClINwraJNTWbZPHQGkpoc9VKOTeZ9t5jNHrFRiddnU6mhr/Br dtD0UTQgjxTikjsWjy1e2qOXIqICvE2BSZecTgmCgpoyRvEQyUE9oSLBd365xMdxIeyF L1IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=RFZCpepgN9sXQyzQPsLbhNkKiYmWa7j+QSyJIBNrFeU=; b=BT1/vq7aXc587ir+r/XCsBS0S1W8mPr87M0sT9GS7I+bKtqJMfDG8zkewSp3bSCIpX o+VvHBAstqlnpOi8rmzh++2wIdIb0B9E70RddbaWIMKR/NXt8HofZPFAKUSXMrer62Eq //jtC7SmtQ4ULvAxYLZCbzqiuwsGhY9hkdi6IF566axD9auGnQoB3sUzngSoWJp2HNck 5nJ4sAPG/ksFhqA0xE2wZzP2q7eFWIHmTceBaAQgZBfx06E1atImJ+RSxQ3DjC8EPN8G nUVznIRV1u+kM/L5N05OJo6lFcqJF6zuBei0FWP0HbH/UG9kafGzBiJisZSAttF7hDrc pPRQ== X-Gm-Message-State: AMCzsaWMOta84uf7z56JEPdcdl9iPaC5LRsIM5ASRyg/+nEZsyV7d63o irpfpPTL9D0enEDxTBnDYRM1bJfgticeVr9fhU8= X-Google-Smtp-Source: AOwi7QDTxfNNPIku2ewBKfjROlnqV20oE9CFUAOVkxSmflfp96XJjVMYa6Xv6xBvzEICQ/t9x0ue0/XdSlPVj/Femg4= X-Received: by 10.84.131.103 with SMTP id 94mr2477378pld.302.1507929398282; Fri, 13 Oct 2017 14:16:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.194 with HTTP; Fri, 13 Oct 2017 14:15:57 -0700 (PDT) From: Kathleen Moriarty Date: Fri, 13 Oct 2017 17:15:57 -0400 Message-ID: To: fud@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Fud] SUIT mailing list X-BeenThere: fud@ietf.org 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: Fri, 13 Oct 2017 21:16:40 -0000 Hello, Please hold off posting any message today to this list and instead save them and post to suit@ietf.org after 12PDT tonight. Sooner is probably fine, but I'm giving some padding as they transition the mail from FUD into SUIT so we have it all in one place. Thank you. -- Best regards, Kathleen From nobody Fri Oct 13 14:19:57 2017 Return-Path: X-Original-To: fud@ietf.org Delivered-To: fud@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6301321B6; Fri, 13 Oct 2017 14:19:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: Kathleen.Moriarty.ietf@gmail.com, fud@ietf.org, smccammon@amsl.com, fud-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150792959618.23739.12672880802877173965.idtracker@ietfa.amsl.com> Date: Fri, 13 Oct 2017 14:19:56 -0700 Archived-At: Subject: [Fud] fud - Cancelling a meeting request for IETF 100 X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 21:19:56 -0000 A request to cancel a meeting session has just been submitted by Stephanie McCammon, on behalf of the fud working group. From nobody Sat Oct 14 02:26:26 2017 Return-Path: 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 E029D132CE7; Sat, 14 Oct 2017 02:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 w3HOycBXwlpG; Sat, 14 Oct 2017 02:26:17 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0AB2132FB1; Sat, 14 Oct 2017 02:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v9E9Pfff004851; Sat, 14 Oct 2017 11:25:41 +0200 (CEST) Received: from [192.168.217.119] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yDfMT3hkfzDMBs; Sat, 14 Oct 2017 11:25:41 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 529665940.764299-6cd553d9f01fd78fe66f72c106c8d92f Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 14 Oct 2017 11:25:40 +0200 Message-Id: To: fud@ietf.org, teep@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Fud] Constrained Node/Network Cluster @ IETF100: DRAFT AGENDA X-BeenThere: fud@ietf.org 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: Sat, 14 Oct 2017 09:26:21 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF100. Remember that there is still quite some potential for changes. The CBOR/SUIT conflict needs to be fixed. Also, maybe CORE and 6TISCH are going to swap so we have more time between the two CORE meetings. All times are SGT (UTC+0800). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten FRIDAY, November 10, 2017 -- Joint meeting of OCF and T2TRG @ OCF meeting venue SATURDAY/SUNDAY -- Hackathon (including various interops) MONDAY, November 13, 2017 0930-1200 Morning Session I Collyer ART dispatch Dispatch WG - 0930-1100 Joint = with ARTAREA Collyer ART httpbis Hypertext Transfer Protocol WG - = 1100-1200 Olivia INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Sophia OPS anima Autonomic Networking Integrated Model = and Approach WG 1330-1530 Afternoon Session I Olivia ART *** core Constrained RESTful Environments WG Padang OPS v6ops IPv6 Operations WG 1550-1720 Afternoon Session II Bras Basah ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Collyer INT homenet Home Networking WG Padang IRTF maprg Measurement and Analysis for Protocols Canning SEC *** suit Software Updates for Internet of Things = WG 1740-1840 Afternoon Session III Padang SEC tls Transport Layer Security WG Canning TSV tsvwg Transport Area Working Group WG TUESDAY, November 14, 2017 0930-1200 Morning Session I Collyer SEC *** ace Authentication and Authorization for = Constrained Environments WG Sophia TSV taps Transport Services WG 1330-1530 Afternoon Session I Olivia ART *** core Constrained RESTful Environments WG Canning OPS v6ops IPv6 Operations WG Bras Basah SEC tokbind Token Binding WG Padang TSV quic QUIC WG 1550-1750 Afternoon Session II Padang IRTF*** t2trg Thing-to-Thing Olivia RTG bier Bit Indexed Explicit Replication WG Sophia SEC oauth Web Authorization Protocol WG WEDNESDAY, November 15, 2017 0930-1200 Morning Session I Sophia INT dnssd Extensions for Scalable DNS Service = Discovery WG Collyer INT ipwave IP Wireless Access in Vehicular = Environments WG - 0930-1030 Collyer INT *** lwig Light-Weight Implementation Guidance WG = - 1100-1200 Bras Basah IRTF icnrg Information-Centric Networking Canning TSV quic QUIC WG 1330-1500 Afternoon Session I Bras Basah ART uta Using TLS in Applications WG Collyer SEC *** teep A Protocol for Dynamic Trusted Execution = Environment Enablement BOF Orchard TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1520-1650 Afternoon Session II Collyer INT intarea Internet Area Working Group WG Orchard SEC oauth Web Authorization Protocol WG THURSDAY, November 16, 2017 0930-1200 Morning Session I Collyer INT 6man IPv6 Maintenance WG Padang IRTF irtfopen IRTF Open Meeting Sophia RTG detnet Deterministic Networking WG Canning SEC tls Transport Layer Security WG 1330-1530 Afternoon Session I Sophia INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Collyer IRTF panrg Path Aware Networking Proposed RG Padang SEC saag Security Area Open Meeting 1550-1750 Afternoon Session II Sophia INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Canning RTG rtgarea Routing Area Open Meeting 1810-1910 Afternoon Session III Orchard SEC curdle CURves, Deprecating and a Little more = Encryption WG Padang TSV tsvarea Transport Area Open Meeting FRIDAY, November 17, 2017 0930-1130 Morning Session I Canning ART httpbis Hypertext Transfer Protocol WG Orchard RTG babel Babel routing protocol WG Collyer TSV tsvwg Transport Area Working Group WG 1150-1320 Afternoon Session I Olivia SEC acme Automated Certificate Management = Environment WG From nobody Sat Oct 14 02:57:32 2017 Return-Path: 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 178ED132CE7; Sat, 14 Oct 2017 02:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 utFmpz6ycxZJ; Sat, 14 Oct 2017 02:57:11 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6431413303F; Sat, 14 Oct 2017 02:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v9E9uwSg029032; Sat, 14 Oct 2017 11:56:58 +0200 (CEST) Received: from [192.168.217.119] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yDg3Z0sJzzDMC8; Sat, 14 Oct 2017 11:56:58 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Sat, 14 Oct 2017 11:56:57 +0200 X-Mao-Original-Outgoing-Id: 529667817.540223-d486016f0e368152bfcc6eeda7833969 Content-Transfer-Encoding: quoted-printable Message-Id: <33CFFF2C-A546-46D8-BD52-6E49F45C5B46@tzi.org> References: To: fud@ietf.org, teep@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Fud] FIXED: Constrained Node/Network Cluster @ IETF100: DRAFT AGENDA X-BeenThere: fud@ietf.org 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: Sat, 14 Oct 2017 09:57:21 -0000 (Sorry for the resend; the previous version missed out on all meetings in the room "VIP A", and I didn't see those conflicts either.) Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF100. Remember that there is still quite some potential for changes. The CBOR/SUIT conflict needs to be fixed. Also, maybe CORE and 6TISCH are going to swap so we have more time between the two CORE meetings. ROLL vs. TEEP is a bit unfortunate, as is DINRG vs. LPWAN vs. DISPATCH. All times are SGT (UTC+0800). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten MONDAY, November 13, 2017 0930-1200 Morning Session I Collyer ART dispatch Dispatch WG - 0930-1100 Joint = with ARTAREA Collyer ART httpbis Hypertext Transfer Protocol WG - = 1100-1200 Olivia INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG VIP A IRTF*** dinrg Decentralized Internet Infrastructure = Proposed RG Sophia OPS anima Autonomic Networking Integrated Model = and Approach WG 1330-1530 Afternoon Session I Olivia ART *** core Constrained RESTful Environments WG Padang OPS v6ops IPv6 Operations WG 1550-1720 Afternoon Session II Bras Basah ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Collyer INT homenet Home Networking WG Padang IRTF maprg Measurement and Analysis for Protocols Canning SEC *** suit Software Updates for Internet of Things = WG 1740-1840 Afternoon Session III Padang SEC tls Transport Layer Security WG Canning TSV tsvwg Transport Area Working Group WG TUESDAY, November 14, 2017 0930-1200 Morning Session I Collyer SEC *** ace Authentication and Authorization for = Constrained Environments WG Sophia TSV taps Transport Services WG 1330-1530 Afternoon Session I Olivia ART *** core Constrained RESTful Environments WG Canning OPS v6ops IPv6 Operations WG Bras Basah SEC tokbind Token Binding WG Padang TSV quic QUIC WG 1550-1750 Afternoon Session II Padang IRTF*** t2trg Thing-to-Thing Olivia RTG bier Bit Indexed Explicit Replication WG Sophia SEC oauth Web Authorization Protocol WG WEDNESDAY, November 15, 2017 0930-1200 Morning Session I Sophia INT dnssd Extensions for Scalable DNS Service = Discovery WG Collyer INT ipwave IP Wireless Access in Vehicular = Environments WG - 0930-1030 Collyer INT *** lwig Light-Weight Implementation Guidance WG = - 1100-1200 Bras Basah IRTF icnrg Information-Centric Networking Canning TSV quic QUIC WG 1330-1500 Afternoon Session I Bras Basah ART uta Using TLS in Applications WG VIP A RTG *** roll Routing Over Low power and Lossy = networks WG Collyer SEC *** teep A Protocol for Dynamic Trusted Execution = Environment Enablement BOF Orchard TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1520-1650 Afternoon Session II Collyer INT intarea Internet Area Working Group WG VIP A IRTF cfrg Crypto Forum Orchard SEC oauth Web Authorization Protocol WG THURSDAY, November 16, 2017 0930-1200 Morning Session I Collyer INT 6man IPv6 Maintenance WG Padang IRTF irtfopen IRTF Open Meeting Sophia RTG detnet Deterministic Networking WG Canning SEC tls Transport Layer Security WG 1330-1530 Afternoon Session I Sophia INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Collyer IRTF panrg Path Aware Networking Proposed RG Padang SEC saag Security Area Open Meeting 1550-1750 Afternoon Session II VIP A ART ice Interactive Connectivity Establishment = WG - 1550-1650 Sophia INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Canning RTG rtgarea Routing Area Open Meeting 1810-1910 Afternoon Session III Orchard SEC curdle CURves, Deprecating and a Little more = Encryption WG Padang TSV tsvarea Transport Area Open Meeting FRIDAY, November 17, 2017 0930-1130 Morning Session I Canning ART httpbis Hypertext Transfer Protocol WG Orchard RTG babel Babel routing protocol WG Collyer TSV tsvwg Transport Area Working Group WG 1150-1320 Afternoon Session I Olivia SEC acme Automated Certificate Management = Environment WG From nobody Sat Oct 14 14:40:21 2017 Return-Path: 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 A39CF127005; Sat, 14 Oct 2017 14:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 MLEkgG8Udrw4; Sat, 14 Oct 2017 14:40:10 -0700 (PDT) Received: from iron01.fraunhofer.de (iron01.fraunhofer.de [153.96.1.54]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDA38126DD9; Sat, 14 Oct 2017 14:40:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2GjAQDh299Z/xoBYJleGQEBAQEBAQEBAQEBBwEBAQEBgy8uZG4nB4NzmVGBdpBwh1EKGAEKgV6DOgKEP1cBAgEBAQEBAgNoKIJqRiwBAQEBAQEmAQEBAQEBIwI+LAEBAQQBASFLGwkCGCoCAicwBgEJCYodBQELjXudZ4InizwBAQEBAQEBAQIBAQEBAQEBAQEBARgFgy2BDnmBUYFqK4FLgTSBPYMoAQECHIMTL4IyBaFEgQiBJoUwjyCFdINVhzOVPgIEBgUCGQGBOViBDlMmXRIBhROBeXSJIoEkAYEQAQEB X-IPAS-Result: A2GjAQDh299Z/xoBYJleGQEBAQEBAQEBAQEBBwEBAQEBgy8uZG4nB4NzmVGBdpBwh1EKGAEKgV6DOgKEP1cBAgEBAQEBAgNoKIJqRiwBAQEBAQEmAQEBAQEBIwI+LAEBAQQBASFLGwkCGCoCAicwBgEJCYodBQELjXudZ4InizwBAQEBAQEBAQIBAQEBAQEBAQEBARgFgy2BDnmBUYFqK4FLgTSBPYMoAQECHIMTL4IyBaFEgQiBJoUwjyCFdINVhzOVPgIEBgUCGQGBOViBDlMmXRIBhROBeXSJIoEkAYEQAQEB X-IronPort-AV: E=Sophos; i="5.43,368,1503352800"; d="scan'208,217"; a="99731597" Received: from mail-mtaka26.fraunhofer.de ([153.96.1.26]) by iron01.fraunhofer.de with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 14 Oct 2017 23:40:05 +0200 X-IronPort-AV: E=Sophos;i="5.43,368,1503352800"; d="scan'208,217";a="264747906" X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaka26.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Oct 2017 23:40:03 +0200 Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v9ELe1RD001893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 14 Oct 2017 23:40:02 +0200 Received: from android-86100a6c0956de20.botanika.local (77.87.48.130) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sat, 14 Oct 2017 23:39:55 +0200 Date: Sat, 14 Oct 2017 23:39:53 +0200 User-Agent: K-9 Mail for Android In-Reply-To: <33CFFF2C-A546-46D8-BD52-6E49F45C5B46@tzi.org> References: <33CFFF2C-A546-46D8-BD52-6E49F45C5B46@tzi.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----8W9VO3K108Y35BDKT595LFDWN77OJ6" Content-Transfer-Encoding: 7bit To: , Carsten Bormann , From: Henk Birkholz Message-ID: <0DCF7156-58D5-40AB-ADD1-19F8D1DA946F@sit.fraunhofer.de> X-Originating-IP: [77.87.48.130] Archived-At: Subject: Re: [Fud] FIXED: Constrained Node/Network Cluster @ IETF100: DRAFT AGENDA X-BeenThere: fud@ietf.org 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: Sat, 14 Oct 2017 21:40:15 -0000 ------8W9VO3K108Y35BDKT595LFDWN77OJ6 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable CBOR/SUIT would be an actual unfortunate conflict=2E This would fracture at= tendance significantly, I think=2E FMPOV, I would also kindly ask to resolve this specific conflict=2E Viele Gr=C3=BC=C3=9Fe, Henk On October 14, 2017 11:56:57 AM GMT+02:00, Carsten Bormann wrote: >(Sorry for the resend; the previous version missed out on all meetings >in the room "VIP A", and I didn't see those conflicts either=2E) >Here is my usual eclectic condensed agenda based on the DRAFT AGENDA >for IETF100=2E Remember that there is still quite some potential for >changes=2E > >The CBOR/SUIT conflict needs to be fixed=2E Also, maybe CORE and 6TISCH >are going to swap so we have more time between the two CORE meetings=2E >ROLL vs=2E TEEP is a bit unfortunate, as is DINRG vs=2E LPWAN vs=2E DISPA= TCH=2E > >All times are SGT (UTC+0800)=2E (You can get pure UTC times on >https://datatracker=2Eietf=2Eorg/meeting/agenda-utc, for those who want t= o >listen from remote=2E) > >Gr=C3=BC=C3=9Fe, Carsten > >MONDAY, November 13, 2017 > >0930-1200 Morning Session I >Collyer ART dispatch Dispatch WG - 0930-1100 Joint with ARTAREA >Collyer ART httpbis Hypertext Transfer Protocol WG - 1100-1200 >Olivia INT *** lpwan IPv6 over Low Power Wide-Area Networks WG >VIP A IRTF*** dinrg Decentralized Internet Infrastructure Proposed >RG >Sophia OPS anima Autonomic Networking Integrated Model and Approach >WG > >1330-1530 Afternoon Session I >Olivia ART *** core Constrained RESTful Environments WG >Padang OPS v6ops IPv6 Operations WG > >1550-1720 Afternoon Session II >Bras Basah ART *** cbor Concise Binary Object Representation >Maintenance and Extensions WG >Collyer INT homenet Home Networking WG >Padang IRTF maprg Measurement and Analysis for Protocols >Canning SEC *** suit Software Updates for Internet of Things WG > >1740-1840 Afternoon Session III >Padang SEC tls Transport Layer Security WG >Canning TSV tsvwg Transport Area Working Group WG > >TUESDAY, November 14, 2017 > >0930-1200 Morning Session I >Collyer SEC *** ace Authentication and Authorization for Constrained >Environments WG >Sophia TSV taps Transport Services WG > >1330-1530 Afternoon Session I >Olivia ART *** core Constrained RESTful Environments WG >Canning OPS v6ops IPv6 Operations WG >Bras Basah SEC tokbind Token Binding WG >Padang TSV quic QUIC WG > >1550-1750 Afternoon Session II >Padang IRTF*** t2trg Thing-to-Thing >Olivia RTG bier Bit Indexed Explicit Replication WG >Sophia SEC oauth Web Authorization Protocol WG > >WEDNESDAY, November 15, 2017 > >0930-1200 Morning Session I >Sophia INT dnssd Extensions for Scalable DNS Service Discovery WG >Collyer INT ipwave IP Wireless Access in Vehicular Environments WG - >0930-1030 >Collyer INT *** lwig Light-Weight Implementation Guidance WG - >1100-1200 >Bras Basah IRTF icnrg Information-Centric Networking >Canning TSV quic QUIC WG > >1330-1500 Afternoon Session I >Bras Basah ART uta Using TLS in Applications WG >VIP A RTG *** roll Routing Over Low power and Lossy networks WG >Collyer SEC *** teep A Protocol for Dynamic Trusted Execution >Environment Enablement BOF >Orchard TSV rmcat RTP Media Congestion Avoidance Techniques WG > >1520-1650 Afternoon Session II >Collyer INT intarea Internet Area Working Group WG >VIP A IRTF cfrg Crypto Forum >Orchard SEC oauth Web Authorization Protocol WG > >THURSDAY, November 16, 2017 > >0930-1200 Morning Session I >Collyer INT 6man IPv6 Maintenance WG >Padang IRTF irtfopen IRTF Open Meeting >Sophia RTG detnet Deterministic Networking WG >Canning SEC tls Transport Layer Security WG > >1330-1530 Afternoon Session I >Sophia INT *** 6lo IPv6 over Networks of Resource-constrained Nodes >WG >Collyer IRTF panrg Path Aware Networking Proposed RG >Padang SEC saag Security Area Open Meeting > >1550-1750 Afternoon Session II >VIP A ART ice Interactive Connectivity Establishment WG - 1550-1650 >Sophia INT *** 6tisch IPv6 over the TSCH mode of IEEE 802=2E15=2E4e WG >Canning RTG rtgarea Routing Area Open Meeting > >1810-1910 Afternoon Session III >Orchard SEC curdle CURves, Deprecating and a Little more Encryption WG >Padang TSV tsvarea Transport Area Open Meeting > >FRIDAY, November 17, 2017 > >0930-1130 Morning Session I >Canning ART httpbis Hypertext Transfer Protocol WG >Orchard RTG babel Babel routing protocol WG >Collyer TSV tsvwg Transport Area Working Group WG > >1150-1320 Afternoon Session I >Olivia SEC acme Automated Certificate Management Environment WG > > >_______________________________________________ >Fud mailing list >Fud@ietf=2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/fud --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------8W9VO3K108Y35BDKT595LFDWN77OJ6 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable CBOR/SUIT would be an actual unfortunate conflict= =2E This would fracture attendance significantly, I think=2E

FMPOV, I would also kindly ask to resolve this specific conflict=2E

Viele Gr=C3=BC=C3=9Fe,

Henk

On October 14, 2017 11:56:57 AM GMT= +02:00, Carsten Bormann <cabo@tzi=2Eorg> wrote:
(Sorry for the resend; the previous version missed o=
ut on all meetings
in the room "VIP A", and I didn't see tho=
se conflicts either=2E)
Here is my usual eclectic condensed agenda bas=
ed on the DRAFT AGENDA
for IETF100=2E  Remember that there is still qu=
ite some potential for
changes=2E

The CBOR/SUIT conflict ne=
eds to be fixed=2E  Also, maybe CORE and 6TISCH
are going to swap so w=
e have more time between the two CORE meetings=2E
ROLL vs=2E TEEP is a=
 bit unfortunate, as is DINRG vs=2E LPWAN vs=2E DISPATCH=2E

All =
times are SGT (UTC+0800)=2E  (You can get pure UTC times on
https://datatracker=
=2Eietf=2Eorg/meeting/agenda-utc, for those who want to
listen fro=
m remote=2E)

Grüße, Carsten

MONDAY, Novemb=
er 13, 2017

0930-1200  Morning Session I
Collyer  ART dispa=
tch Dispatch WG - 0930-1100 Joint with ARTAREA
Collyer  ART httpbis Hy=
pertext Transfer Protocol WG - 1100-1200
Olivia   INT *** lpwan IPv6 o=
ver Low Power Wide-Area Networks WG
VIP A    IRTF*** dinrg Decentraliz=
ed Internet Infrastructure Proposed RG
Sophia   OPS anima Autonomic Ne=
tworking Integrated Model and Approach WG

1330-1530  Afternoon S=
ession I
Olivia   ART *** core Constrained RESTful Environments WG
Padang   OPS v6ops IPv6 Operations WG

1550-1720  Afternoon Ses=
sion II
Bras Basah ART *** cbor Concise Binary Object Representation M=
aintenance and Extensions WG
Collyer  INT homenet Home Networking WGPadang   IRTF maprg Measurement and Analysis for Protocols
Canning=
  SEC *** suit Software Updates for Internet of Things WG

1740-1=
840  Afternoon Session III
Padang   SEC tls Transport Layer Security W=
G
Canning  TSV tsvwg Transport Area Working Group WG

TUESDA=
Y, November 14, 2017

0930-1200  Morning Session I
Collyer  =
SEC *** ace Authentication and Authorization for Constrained Environments W=
G
Sophia   TSV taps Transport Services WG

1330-1530  Aftern=
oon Session I
Olivia   ART *** core Constrained RESTful Environments W=
G
Canning  OPS v6ops IPv6 Operations WG
Bras Basah SEC tokbind To=
ken Binding WG
Padang   TSV quic QUIC WG

1550-1750  Afterno=
on Session II
Padang   IRTF*** t2trg Thing-to-Thing
Olivia   RTG =
bier Bit Indexed Explicit Replication WG
Sophia   SEC oauth Web Author=
ization Protocol WG

WEDNESDAY, November 15, 2017

0930=
-1200  Morning Session I
Sophia   INT dnssd Extensions for Scalable DN=
S Service Discovery  WG
Collyer  INT ipwave IP Wireless Access in Vehi=
cular Environments WG - 0930-1030
Collyer  INT *** lwig Light-Weight I=
mplementation Guidance WG - 1100-1200
Bras Basah IRTF icnrg Informatio=
n-Centric Networking
Canning  TSV quic QUIC WG

1330-1500  A=
fternoon Session I
Bras Basah ART uta Using TLS in Applications WG
VIP A    RTG *** roll Routing Over Low power and Lossy networks WG
C=
ollyer  SEC *** teep A Protocol for Dynamic Trusted Execution Environment E=
nablement BOF
Orchard  TSV rmcat RTP Media Congestion Avoidance Techni=
ques WG

1520-1650  Afternoon Session II
Collyer  INT intare=
a Internet Area Working Group WG
VIP A    IRTF cfrg Crypto Forum
=
Orchard  SEC oauth Web Authorization Protocol WG

THURSDAY, Novem=
ber 16, 2017

0930-1200  Morning Session I
Collyer  INT 6man=
 IPv6 Maintenance WG
Padang   IRTF irtfopen IRTF Open Meeting
Sop=
hia   RTG detnet Deterministic Networking WG
Canning  SEC tls Transpor=
t Layer Security WG

1330-1530  Afternoon Session I
Sophia  =
 INT *** 6lo IPv6 over Networks of Resource-constrained Nodes WG
Colly=
er  IRTF panrg Path Aware Networking Proposed RG
Padang   SEC saag Sec=
urity Area Open Meeting

1550-1750  Afternoon Session II
VIP=
 A    ART ice Interactive Connectivity Establishment WG - 1550-1650
So=
phia   INT *** 6tisch IPv6 over the TSCH mode of IEEE 802=2E15=2E4e WG
Canning  RTG rtgarea Routing Area Open Meeting

1810-1910  After=
noon Session III
Orchard  SEC curdle CURves, Deprecating and a Little =
more Encryption WG
Padang   TSV tsvarea Transport Area Open Meeting
FRIDAY, November 17, 2017

0930-1130  Morning Session I<=
br />Canning  ART httpbis Hypertext Transfer Protocol WG
Orchard  RTG =
babel Babel routing protocol WG
Collyer  TSV tsvwg Transport Area Work=
ing Group WG

1150-1320  Afternoon Session I
Olivia   SEC ac=
me Automated Certificate Management Environment WG


<=
br />Fud mailing list
Fud@ietf=2Eorg
https://www=2Eietf=2Eorg/mailman/listinfo/fud=

--
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------8W9VO3K108Y35BDKT595LFDWN77OJ6--