Trusted Execution Environment Provisioning
charter-ietf-teep-01

[Ballot comment]
No objection to the charter, but we should clarify two points.

1. I scratched my head: What does an "application layer protocol" mean in this context?

This working group aims to develop an application layer protocol providing TEEs
with lifecycle management and security domain management for trusted
applications.

What would the difference with?
This working group aims to develop a management protocol providing TEEs
with lifecycle management and security domain management for trusted
applications.

Or even?
This working group aims to develop a protocol providing TEEs
with lifecycle management and security domain management for trusted
applications.

2.
Second, a solution
document that describes the above-described functionality that will be
developed.

A solution document? I believe it's too vague.
I understand you want to specify a new protocol. You should clarify and adapt the milestones.


Editorial:
- Confused by the comma in the following sentence:

For example, implementations of the TEE
concept have been developed by ARM, and Intel using the TrustZone and the SGX
technology, respectively.

Do you want to say?
For example, implementations of the TEE
concept have been developed by ARM and Intel, using the TrustZone and the SGX
technology, respectively.

Or maybe better?
For example, implementations of the TEE
concept have been developed by ARM using the TrustZone and by Intel using the SGX
technology.

[Ballot comment]
"providing TEEs providing lifecycle management" --> something is wrong there

"The group will produce the following deliverables. The first draft is" --> kind of implies that the deliverable is a draft rather than an RFC

s/other relevant standards/other relevant standards groups/

[Ballot comment]
No objection to this charter, but do the milestones for the Solutions draft make sense? I'm reading

Date Milestone
Jul 2019         Begin WGLC for Solution document
Jan 2019 Progress Architecture document to the IESG for publication
Dec 2018 Begin WGLC for Architecture document
Aug 2018 Progress Solution document to the IESG for publication
Mar 2018 Adopt a solution document
Mar 2018 Adopt an Architecture document

as saying the draft goes to the IESG in Aug 2018 and enters WGLC in July 2019 ...

[Ballot comment]
The milestones seem, um, aspirational.

I personally think that architecture (and similar) documents should be published as RFCs, as they are really useful for newcomers to the field (or people wanting to deploy) to understand how things fit together - this is just an editorial comment, no change neeeded, etc.

[Ballot comment]
> The group will produce the following deliverables. The first draft is an
> architecture document describing the involved entities, their relationships,
> assumptions, the keying framework and relevant use cases.

Given the guidance at , I would like to see the charter specifically indicate whether this deliverable will be sent to the IESG for publication, or simply produced for the working group's internal use.

[Ballot comment]
I'm a Yes with comments, but I'm a Yes whether anything changes or not. ...

I wasn't parsing this text well:

"This working group aims to develop an application layer protocol providing TEEs
with a lifecycle management for trusted applications and security domain
management."

Does

"This working group aims to develop an application layer protocol providing TEEs
providing lifecycle management and security domain management for trusted applications."

make sense?

Honest question - would anybody ever expose this kind of API?

"A security domain allows a service provider's applications to be isolated so
that one security domain cannot be influenced by another, unless it exposes an
API to allow it."

If the answer is "yes", is there any work on advice about this that would be worth mentioning in the charter?

I may be misremembering, but is Global Platform going to remain in the picture after TEEP is chartered?