Subject: [Suit] Suit Charter Updates Process Question

From: Suhas Nandakumar <[email-masked]>
Date: Wed, 22 Nov 2017 15:34:06 -0800

Hi Kathleen and Chairs

I am bit confused on the actual process followed in updating the Suit
Charter. It looks like the current charter doesn’t seem to reflect fully
the consensus or discussion points from the BOF.

Also it would have been of great help if the updated charter was sent to
the SUIT mailing list for questions/consensus before getting uploaded to
the datatracker. I had to accidentally find it embedded in the BOF report
sent to saag mailing list.

Should questions/comments about the current charter sent to Suit mailing
list be the right way to follow up ? Also, Who is actually updating the
charter?

Please advice

Thanks

Suhas Nandakumar

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Nov 2017 12:35:44 -0500

Suhas Nandakumar <[email-masked]> wrote:
    > Charter. It looks like the current charter doesn’t seem to reflect
    > fully the consensus or discussion points from the BOF.

I think that you should consider that the text gets uploaded on a
quasi-periodic basis so that we can all be talking about the same thing.

    > Also it would have been of great help if the updated charter was sent
    > to the SUIT mailing list for questions/consensus before getting
    > uploaded to the datatracker. I had to accidentally find it embedded in
    > the BOF report sent to saag mailing list.

Yes, I agree that this is less than ideal.
But, for many people this is a down week, both because of US Thanksgiving and
because it's the week after the IETF meeting, and many people need recovery
time, so please be patient.

    > Should questions/comments about the current charter sent to Suit
    > mailing list be the right way to follow up ? Also, Who is actually
    > updating the charter?

Generally, the BOF chairs and/or proponents do that in consultation with the
sponsoring AD and the ML.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Mon, 27 Nov 2017 19:24:33 +0000

Comments inline below.

> -----Original Message-----
> From: Michael Richardson [mailto:[email-masked]]
> Sent: Thursday, November 23, 2017 12:36 PM
> To: Suhas Nandakumar <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Suit] Suit Charter Updates Process Question
> 
> 
> I think that you should consider that the text gets uploaded on a quasi-periodic
> basis so that we can all be talking about the same thing.

The latest charter text is posted on the SUIT Datatracker page here:

https://datatracker.ietf.org/doc/charter-ietf-suit/

This text was updated after the BoF on November 15th.

The charter text at this link is intended to represent the consensus reached from the hums during BoF. To confirm these changes on the list, we have posted updated charter text. If anyone believes there are concerns with the charter text that have not been adequately addressed, please raise those concerns ASAP.

> time, so please be patient.

Michael, thanks for responding while I was away recovering from jet lag and enjoying time with family over the Thanksgiving holiday. 

I will post to the list if any changes are made to the charter going forward.

>     > mailing list be the right way to follow up ?

Yes. Please send any concerns to the list. Also, please provide new suggested charter text for any proposed changes. This will help everyone better consider the change.

>     > Also, Who is actually

Dave and I are working with Kathleen to edit the charter based on the ongoing discussion on the list. Kathleen has been posting changes as they have occurred to the Datatracker.

> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works  -
> = IPv6 IoT consulting =-
> 
> 

Regards,
Dave

---

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 28 Nov 2017 08:04:33 +0000

Thanks David and Michael for the responses.  I have followed up with few
concerns/requests correspondences  via email to the list for charter
updates and scope of the WG.
Here is one on the charter text suggestions.
https://www.ietf.org/mail-archive/web/suit/current/msg00239.html

Hope this helps

Thanks
Suhas

On Mon, Nov 27, 2017 at 11:24 AM, Waltermire, David A. (Fed) <
[email-masked]> wrote:

> quasi-periodic
> The charter text at this link is intended to represent the consensus
> reached from the hums during BoF. To confirm these changes on the list, we
> have posted updated charter text. If anyone believes there are concerns
> with the charter text that have not been adequately addressed, please raise
> those concerns ASAP.
>
> Michael, thanks for responding while I was away recovering from jet lag
> and enjoying time with family over the Thanksgiving holiday.
>
> Yes. Please send any concerns to the list. Also, please provide new
> suggested charter text for any proposed changes. This will help everyone
> better consider the change.
>
> >     > Also, Who is actually
> >     > updating the charter?
> >
> Dave and I are working with Kathleen to edit the charter based on the
> ongoing discussion on the list. Kathleen has been posting changes as they
> have occurred to the Datatracker.
>
> >
> > --

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 28 Nov 2017 21:52:59 -0700

> On Nov 27, 2017, at 12:24 PM, Waltermire, David A. (Fed) <[email-masked]> wrote:
> 
> 

Yep, I have concerns. I don't think what I see in the tracker is at all representing consensus from the list or the BOF. 

Can we get an actual answer to who is editing this and who is deciding what has consensus or not? We also have an issue in that the charter-ietf-suit-00-07 in the data tracker and charter-ietf-suit-00-08 look identical to me. Is this a tracker bug? Do you think they changed? 

I think whoever is editing the charter should be emailing it to the suit list along with changes and explanation of what changed. There has been a lot of discussion and agreement on the list and I do not see any changes in the charter to reflect nor do I see discussion on the list to indicate what went in the charter and what people decided there was no consensus on. 

Could someone on the IESG post the text they see for this and let me know if has changed since the BOF?

Thanks, Cullen

---

From: Adam Roach <[email-masked]>
Date: Wed, 29 Nov 2017 00:05:04 -0600

> Could someone on the IESG post the text they see for this and let me know if has changed since the BOF?

This seems to capture the changes between the BOF version and the 
version that is up for approval:

https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-suit%2Fwithmilestones-00-05.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-suit%2Fwithmilestones-00-08.txt

/a

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 29 Nov 2017 06:04:34 -0700

Thanks Adam.

OK, the text you are getting in that diff is different that what I got from the data tracker as the -08 version. Suhas also got the same thing as me.  Both Hannes and I have been surprised by what is in the tracker and I think it has become clear to me that the tracker is broken.  From a procedural point of view, I think you need to email the charter, preferably with diffs, to the mailing list. I for one have not reviews this text in Adam's diff.   I'm sure other people have also not seen this. It seems reasonable to send a clear charter to the list and give people reasonable time to comment on that before the IESG makes a decision. 

I don't believe this text in adams diff represents consensus on the list so back to question that no one seems to answer   ... Who is editing this text and who is deciding consensus on the list?

As FYI ... the text I got from data tracker for -08 was 

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 firmware in IoT devices.

A firmware update solution consists of several components, including:
- A mechanism to transport firmware images to compatible 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 led to
additional functionality, requiring a contemporary standardized solution to be
defined.

This group will focus on defining a firmware update solution that will be
usable on Class 1 (as defined in RFC 7228) devices, that is usable on devices
with ~10 KiB RAM and ~100 KiB flash.  The solution may apply to more capable
devices as well.  This group will not define any new transport or discovery
mechanisms, but may describe how to use existing mechanisms within the solution.

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 are
challenges with misaligned incentives and complex value chains.  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 several documents, namely:
- An IoT firmware update architecture that includes a description of the
involved entities, security threats, and assumptions. - One or more manifest
format specifications.

The initial focus of this group will be development of the contents of a
manifest. Once there is general agreement on the contents, the group will pick
a small number of formats (and their associated cryptographic mechanisms) to
encode the manifest. A lower number of formats is preferred to reduce code size
for supporting decoders on devices receiving a manifest and to maximize
interoperability of solutions. To support a wide range of deployment scenarios,
the formats are expected to be expressive enough to allow the use of different
software sources and permission models.

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 firmware development practices in the embedded industry. 
Software update solutions that target updating software other than the firmware
binaries are also out of scope.

This group will aim to maintain a close relationship with silicon vendors and
OEMs that develop IoT operating systems.

> On Nov 28, 2017, at 11:05 PM, Adam Roach <[email-masked]> wrote:
> 
> This seems to capture the changes between the BOF version and the version that is up for approval:
> 
> _______________________________________________
> Suit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/suit

---

From: Michael Richardson <[email-masked]>
Date: Wed, 29 Nov 2017 10:25:04 -0500

{trimming the CC list a bit}

    > https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-suit%2Fwithmilestones-00-05.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-suit%2Fwit…

Adam: Given that Cullen has raised questions about whether the datatracker is
      returning the correct text, it would have been better to have posted
      the text to the list....  The side-by-side diff format wouldn't have
      worked, but rfcdiff has a unidiff format I think.

      {On this charter I wish that we had github-style pull requests that we could
      discuss in the mailing list....   I seem to see the same text Cullen saw, so
      that's good.}

Three minor editing suggestions for the chairs, or whomever is editing:
1) the bullet points were better off with *, and the third bullet point got
   wrapped.  Also the bullet points in "In particular this group aims..."
   have gotten wrapped and are hard to see.

2) I suggest that "In June of 2016 the "... be moved up.  I'd even make it
   the first intro paragraph, if not the second.  it's awkward where it is.

3) RFC 4108... More than... I'd have written, "While RFC4108...; in the ten
   years since, greater experience with..."
   But, this is also creates more complex sentence structure, which is often
   a bad thing.

On substantive comments about the -08 text:

many have pointed out that this makes no sense:

  A lower number of formats is preferred to reduce code size
  for supporting decoders on devices receiving a manifest and to maximize
  interoperability of solutions.

constrained devices are unlikely to support more than one format.
The reason to have fewer formats is so that tools to generate and audit
manifests will be easier to develop and interoperate.  Change to:

  A lower number of formats is preferred as it increases the likely hood
  that there will be widely available and complete tools for generating
  and auditing the manifests.
  The number of formats is unlikely to affect the devices receiving the
  updates and they are likely to support only a single format.

>mechanism for use by rich operating systems, like Linux, but instead this group

I suggest maybe: "s/like Linux/like Linux, or Android/"

(I think it's worth marking Android which can upgrade via blob as out of
scope: at least for now. There are many other interactions involving other
OTA updates, and I think we all agree that APKs or applications are out of
scope. Apple iPhone iOS being a single vendor totally vertical integration, I
don't think will ever be in scope)

>binaries are also out of scope.

I'm not sure what this means.  It seems like maybe it might be excluding an
embedded system from updating the firmware in it's wifi or 3G baseband
processor.   Maybe it has to do with software configuration stuff?

If Android or home routers that run Linux were in scope, would an update to
the DTS be in scope?  https://elinux.org/Device_Tree_Reference  I know that
there are other embedded operating systems that contain configuration data.

For instance, two identical actuators might run exactly the same code, yet
one of them controls a normally open valve on GPIO pin 12 and the other
controls a normally closed value on GPIO pin 9.  Is the update of what might
be considered configuration in scope?    It probably all looks like firmware
to the installers...

>OEMs that develop IoT operating systems.

It would be nice if someone could indicate how we are going to do that.
For instance, would having an interim meeting at some embedded conference be
within this scope?    Should have have some formal liason process?

Would the chairs be willing to maintain a set of canonical (having been
subject to a WG consensus call...) slides as to what we are doing, where we
are, such that participants in the WG would feel confident representing the
views of the WG in other fora?

---

From: Eliot Lear <[email-masked]>
Date: Wed, 29 Nov 2017 16:38:45 +0100

Hi Michael,

On 11/29/17 4:25 PM, Michael Richardson wrote:
> scope. Apple iPhone iOS being a single vendor totally vertical integration, I don't think will ever be in scope)

I don't mind one way or the other,  but in the new text, there is one
aspect that confuses me:

> ... but instead this group  will focus on firmware development
practices in the embedded industry.   

development practices or distribution mechanisms?

The former seems to be quite broad.

Eliot

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 29 Nov 2017 11:18:24 -0500

To briefly answer some of the questions asked on process, I am
updating the charter, per the consensus decisions by the chairs.  The
chairs typically make the consensus calls for all working groups and
BoFs.  The calls were made in the meeting and reflected in the charter
text that was posted shortly after the meeting.  The charter review
text is separate from a working charter in how the tools handle it.
For a BOF, there should only be working text, so I am not sure what
happened to create working text.

The chairs will respond to the other questions asked.  I will wait for
their assessment before any changes are made to the text or to the
charter review since it has been posted for a couple of weeks.  If
there are just simple edits, there is no reason to postpone the
telechat date.  The WG decided some of the major decisions would
happen within the WG and not in the charter discussion, which should
alleviate some possible concerns.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 29 Nov 2017 11:40:19 -0500

Also, the difference between 7 and 8 was an attempt to fix the wrap
around issue on bullets, but it was not successful.  This is just
editorial and can be adjusted at any time.

Best regards,
Kathleen

-- 

Best regards,
Kathleen