Re: [Suit] SUIT rechartering: proposed text

[Brendan Moran <[e-mail]>]

As mentioned at the virtual interim, there was already some proposed charter text circulated. Here it is again:

To support the manifest format(s) defined by this group, it will also define formats and protocols that enable a Status Tracker to determine if a particular manifest could be successfully deployed to a device and determine if an operation was successful.

Specifications of names or numbers will enable the use of manifests, their precursors, and their successors within existing or future protocols.

This most immediate beneficiary of this charter text is draft-moran-suit-mud.

Given how trivial this draft is, I think it could have reasonably quick milestones, but it is, of course, dependent on draft-ietf-suit-manifest. I’d be appreciative of any suggestions on the timeline for this draft.

Best Regards,
Brendan

On 16 Feb 2021, at 22:39, Michael Richardson <[e-mail]<mailto:[e-mail]>> wrote:


Brendan Moran <[e-mail]<mailto:[e-mail]>> wrote:
   bm> As a part of proposing several new drafts, I was asked to propose some new charter text that would enable the working group to address the new drafts.

   bm> The drafts in question are:

   bm> * draft-moran-suit-mud
   bm> * draft-moran-suit-report
   bm> * draft-birkholz-rats-suit-claims (TBD, maybe SUIT, maybe RATS)

As a RATS architecture editor, I prefer to do this document in SUIT.
Sure, RATS should be consulted, but the expertise in getting the claim
written right exists in SUIT, not RATS.

   bm> draft-moran-suit-mud proposes a method to anchor MUDs with the same
   bm> trust and fetch mechanisms as SUIT.

   bm> draft-moran-suit-report proposes a document format for reporting the
   bm> results of applying a SUIT update or secure execution using a SUIT
   bm> manifest.

   bm> draft-birkholz-rats-suit-claims proposes number assignments for EAT
   bm> claims that contain evidence generated during execution of a SUIT
   bm> manifest.

   bm> I would like to add a single paragraph to the charter:

To support the manifest format(s) defined by this group, it will also define
formats that enable precursor or successor operations around the use of
the manifests. Additional specifications of names or numbers will enable
the use of manifests, their precursors, and their successors within
existing or future protocols.

That seems like fine text.
I am not sure that an external reviewer will understand how it implies that
three documents are in scope.  It may be just too abstract for some IESG
members.  The trend seems to be that charters are very specific.
I think that the "precusor or successor operations" is the part that might be
too abstract.  Maybe that part should spell out what you want.

} To support the manifest format(s) defined by this group, it will also
} define formats and protocols that enable a Status Tracker to determine if a
} particular manifest could be successfully deployed to a device, and
} determine if an operation was successful.
} Additional specifications of names or numbers will enable the use of
} manifests, their precursors, and their successors within existing or future protocols.

--
Michael Richardson <[e-mail]<mailto:[e-mail]>>   . o O ( IPv6 IøT consulting )
          Sandelman Software Works Inc, Ottawa and Worldwide


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.