Subject: [Suit] Benjamin Kaduk's No Objection on charter-ietf-suit-01-02: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 01 Dec 2021 21:43:33 -0800

Benjamin Kaduk has entered the following ballot position for
charter-ietf-suit-01-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-suit/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Did we lose a milestone corresponding to draft-ietf-suit-manifest, in
the update?  I'm not sure if I'm just getting confused by the diff
formatting or not.

  To support a wide range of deployment scenarios, the formats are
  expected to be expressive enough to allow the use of different firmware
  sources and permission models.

This is perhaps a little too vague about what "different firmware
sources and permission models" would entail.  I'm wary of putting too
much detail into the charter, here, but perhaps we should say that the
WG will think about how much expressivity is desired on these axes?

I would also echo Éric's question about the well-known nature of the
"SUIT Status Tracker".

  In addition, the SUIT WG will work with the RATS WG to specify claims
  related to the SUIT Status Tracker that can be used to provide evidence
  in support of the architecture that has already been defined by the RATS
  WG.

What makes a claim "related to the SUIT Status Tracker"?
Also, the phrase "to provide evidence in support of the architecture"
leaves me uncertain if it says what it means -- are we supporting the
RATS architecture, or are we supporting something else while fitting
into the RATS architecture?

  - inclusion of MUD file as defined in RFC 8520.

grammar nit: singular/plural mismatch
Also, the MUD file is deifned in 8520, not inclusion of it.  We could
probably come up with an alternative phrasing that avoids the misparse.

  * A secure method for an IoT device to report on firmware update status.

This seems like it might be a new protocol, which is a little at odds
with the earlier portions of the charter that wanted to avoid new
transport or discovery mechanisms.

---

From: Russ Housley <[email-masked]>
Date: Thu, 2 Dec 2021 16:10:49 -0500

It looks like we dropped it in the editing process.  I suggest:

Dec 2021     Submit "Manifest Format" to the IESG for publication as a Proposed Standard.

We just completed the consensus call of the MTI algorithms for this document, so the WG Last Call should not be far behind.

> WG will think about how much expressivity is desired on these axes?

Ben, given that the SUIT architecture document has already been published as RFC 9019, I think the scope is reasonably bounded.

> I would also echo Éric's question about the well-known nature of the

Likewise, the SUIT Status Tracker is defined in RFC 9019.

> into the RATS architecture?

The RATS WG Chairs and SUIT WG Chairs are trying to schedule a joint virtual interim session to sort out some of the questions that you are asking.  That said, we wanted to have something in the charter to cover the outcome of that discussion.

> probably come up with an alternative phrasing that avoids the misparse.

The inclusion of a MUD file in a SUIT manifest is the intent.

> transport or discovery mechanisms.

Yes, a small CBOR report is defined.  However, like the SUIT manifest, the group was not planning to specify a transport for the message.

Russ

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 2 Dec 2021 21:27:31 +0000

Hi!

> -----Original Message-----
> From: Suit <[email-masked]> On Behalf Of Russ Housley
> Sent: Thursday, December 2, 2021 4:11 PM
> To: Ben Kaduk <[email-masked]>
> Cc: SUIT Working Group <[email-masked]>; [email-masked]; IESG
> <[email-masked]>
> Subject: Re: [Suit] Benjamin Kaduk's No Objection on charter-ietf-suit-01-02:
> (with COMMENT)
> 
> Ben:
> 
> We just completed the consensus call of the MTI algorithms for this document,
> so the WG Last Call should not be far behind.

(someone more knowledge of the datatracker back-end should correct me if there is more process nuance)

Nothing got lost.  A diff won't show this.  We're seeing an artifact of how new milestones are bound to charter revisions.

The "production"/already approved charter at https://datatracker.ietf.org/wg/suit/about/ (and officially https://datatracker.ietf.org/doc/charter-ietf-suit/01/ ) already has this milestone for a manifest format.  It is the only outstanding one left and targeted for Feb 2022.

With the re-charter, https://datatracker.ietf.org/doc/charter-ietf-suit/, one has to propose _new_ milestones that are above an beyond those already approved.  If a manifest format milestone would be added now in the list of "proposed milestones" with the proposed (-01-02) charter, there were would two milestones for the same thing upon approval (one from the existing charter and one from the newly approved one).

> > expected to be expressive enough to allow the use of different
> > firmware  sources and permission models.
> >
> Ben, given that the SUIT architecture document has already been published as
> RFC 9019, I think the scope is reasonably bounded.
> 
> >

I committed to putting in text to the effect of the following during the telechat today:

OLD
To enable SUIT Status Tracker functionality

NEW
To enable SUIT Status Tracker functionality (per RFC9019)

Regards,
Roman

---

From: Russ Housley <[email-masked]>
Date: Thu, 2 Dec 2021 16:30:18 -0500

Roman:

> On Dec 2, 2021, at 4:27 PM, Roman Danyliw <[email-masked]> wrote:
> 
> Hi!
> 

The place it was missing was in the text that I sent to you to kick off the recharter process.

> To enable SUIT Status Tracker functionality (per RFC9019)

Works for me.

Russ

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 3 Dec 2021 12:53:42 -0800

> Dec 2021     Submit "Manifest Format" to the IESG for publication as a Proposed Standard.

I'm willing to believe Roman's analysis from the follow-up -- I was just
looking at
https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-suit%2Fwithmilestones-01.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-suit%2Fwithmilestones-01-02.txt
which does something I don't fully understand to merge a given charter text
and its milestones, and then diff the resulting text.  My note about "just
getting confused by the diff formatting" was triggered by a half-remembered
previous instance where the diff output showed something not quite
reflective of reality.  Perhaps when preparing the merged
charter+milestones for draft charters, it should also incorporate
preexisting milestones from the previous in-force charter ... but perhaps
the object model for milestones doesn't allow that kind of associate with
an approved charter version.

> We just completed the consensus call of the MTI algorithms for this document, so the WG Last Call should not be far behind.

Excellent!

> Ben, given that the SUIT architecture document has already been published as RFC 9019, I think the scope is reasonably bounded.

Okay, I can accept that.  I'd prefer more precision in the charter, but we
are probably past the point of diminishing returns...

> The RATS WG Chairs and SUIT WG Chairs are trying to schedule a joint virtual interim session to sort out some of the questions that you are asking.  That said, we wanted to have something in the ch…

I'm happy to have something in the charter on this topic and acknowledge
that there is still some uncertainty that needs to be worked out.
I think I would apply s/to provide evidence in support of the
architecture/to provide evidence that can be consumed by other elements of
the architecture/, since "in support of" can mean both "we think this
architecture is a good idea" and "we provide some information that fits
into the architecture and lets someone instantiate the architecture".

> The inclusion of a MUD file in a SUIT manifest is the intent.

Maybe "inclusion of files in the MUD format defined by RFC 8520"?

> Yes, a small CBOR report is defined.  However, like the SUIT manifest, the group was not planning to specify a transport for the message.

Okay.

Thanks,

Ben