Re: [Suit] SUIT rechartering: proposed text

[Dave Thaler <[e-mail]>]

Michael Richardson 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.



[dt] there are two parts of draft-birkholz-rats-suit-claims.

Section 3.1 contains things that are not SUIT specific and should be merged into the EAT document.

The TEEP protocol for example uses them directly, and would even if it didn’t use SUIT.

Section 3.2 contains things that are SUIT specific and I agree putting them in SUIT would be appropriate.





    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.



The AD’s suggested phrase to the chairs back in December was along the idea of
“developing and publishing mechanisms to enable SUIT integration and interoperability with other IoT technologies and ecosystems”.
And I think that phrasing would be helpful.

Does anyone else have comments?

Dave




} 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