Is it in scope: TA depends on another TA and related installation? about architecture HOT 7 CLOSED

From IETF#103:

Issue #13: couple of use-cases described for dependencies among TAs, e.g.:
- one TA that acts as a launcher for one or more other TAs
- one or more TAs that require access to, say, a crypto library which is deployed as a
discrete binary (perhaps because it's from a different vendor/maniuacturer)
Nancy C-W: recommend adding a couple of example use cases to the document for
illustrative purposes,

from architecture.

This issue is related to the work in the IETF SUIT working group

from architecture.

I added text in issue #35. It does make sense to add a short sentence talking about an example use case.

An example use case where one TA is needed by one or more TAs is code related to a crypto API that is need by a TA that implements a secure storage mechanism as well as by a TA that offers attestation functionality. Whenever the secure storage TA will be installed it has to list a dependency in its manifest so that the TA offering the crypto API is also installed (in the correct version).

from architecture.

The dependency handling of TAs is an advanced feature. We suggest to address this in a future version.

from architecture.

We need a naming scheme to indicate the dependency among TAs that can be verified.

from architecture.

Section 5.3 says "This is also the case when a Client App uses multiple TAs, or when one TA depends on anther TA in a software dependency (see section TBD)." so there is still a TBD in the document here.

from architecture.

@ncamwing this issue is now ready to be closed based on #75 being merged

from architecture.