Re: [Teep] The TEEP WG has placed draft-yang-teep-usecase-for-cc-in-network in state "Call For Adoption By WG Issued"

Hi, my brief initial review of the draft:

I think this is a useful draft and it’s a good idea to provide a guidance for MEC/CAN usage of confidential computing.

Abstract:
The abstract needs to be made clearer. Some things that are missing in the abstract: (1) what problem or need is being addressed; (2) on which components in the network the TEEs are assumed to be deployed; 

Introduction:
“In the scenario of confidential computing in network, network users will attest the TEE in confidential computing and provision private data and applications to that TEE by network. This network could be a MEC[MEC], CAN or other network that provide computing resource to users.” - the introduction can improved by describing early on what the users represent in this scenario, and where the TEEs are located in the network fabric. Similar to the abstract - what is the motivation for doing this? Simply having it _possible_ is not enough of a reason.

Notional Architecture:
The Data Owner is mentioned without introduction or explanation. It’s important to clarify who the data owner is? Same as the user deploying data? Perhaps there are other roles, such as the data source (such as the connected vehicle), the application source (a third party application provider?), data owner (the owner of the vehicle or the operator of the vehicle at a specific point in time?) 

Use cases:

Sections 4.1-4.5 enumerate various combinations of delivering the Personalization Data (PD), Trusted Application (TA) and Untrusted applications (UA). Some context and examples for each of them would both help readability and provide clearer motivations for each of the  enumerated use cases.

Best regards,
Nicolae

> On 13 Aug 2022, at 06:36, yangpenglin@chinamobile.com wrote:
> 
> Hi，
> 
> In my understanding, some deploy steps are better to be remained in this draft, and some could be defined in a loose sequence. 
> 
> First, we should make sure that all the PD is unpackaged or processed inside TA. For example in section 4.1 process column, since the package contains (UA, TA and PD), the package should be unpackaged inside TEE, and then let the TEE export the UA to REE. 
> 
> Seond, we also need to consider if the TA has the ability of network communication. In some scenarios like SGX, if there is no middleware like libos or web assembly, the trusted process may have no network ability. And the TEEP broker or the UA will have to act as the role of network communication. This also means UA have to deployed before TA and PD. In Dave's feedback of 9th July, the sequence problem is also been mentioned.
> 
> "It talks about the TAM (which is the relying party in attestation) forwarding the attestation result to the user (data provider).  I agree the data provider needs to get it if it wants to communicate with the TEEP agent to provide a decryption key or whatever else.  However, I don’t think it has to get it from the TAM, but could get it directly from the TEEP Agent  For example, if the data provider has its own TAM just for handing out the key, then the TEEP Agent would reach out to the data provider and provide the attestation payload directly.  So I think the language should be loosened here rather than overly constrained."
> 
> I will try to resolve this problem in next version.
> 
> BR
> Penglin
> 
> 
> 
> On 8/11/2022 9:13 AM, Meiling Chen wrote:
>>  Hi Daniel,
>> Thanks for your support.
>>  Agree with you, deployment options no need every one in detail.
>> 
>> Best,
>> Meiling 
>> From: Daniel Migault <mailto:mglt.ietf@gmail.com>
>> Date: 2022-08-10 20:34
>> To: Meiling Chen <mailto:chenmeiling@chinamobile.com>
>> CC: IETF Secretariat <mailto:ietf-secretariat-reply@ietf.org>; draft-yang-teep-usecase-for-cc-in-network@ietf.org <mailto:draft-yang-teep-usecase-for-cc-in-network@ietf.org>; teep-chairs@ietf.org <mailto:teep-chairs@ietf.org>; teep@ietf.org <mailto:teep@ietf.org>
>> Subject: Re: [Teep] The TEEP WG has placed draft-yang-teep-usecase-for-cc-in-network in state "Call For Adoption By WG Issued"
>> As mentioned during the IETF114, I support the adoption of the document and I am interested in reviewing the document. 
>> 
>> Yours, 
>> Daniel
>> 
>> On Sun, Aug 7, 2022 at 9:25 PM Meiling Chen <chenmeiling@chinamobile.com <mailto:chenmeiling@chinamobile.com>> wrote:
>> Hi folks,
>> As one of the authors, I support the WG adoption. And I also notice that this draft need more reviewers, if anyone have interest, feel free to comments.
>> 
>> Best,
>> Meiling
>>  
>> From: IETF Secretariat <mailto:ietf-secretariat-reply@ietf.org>
>> Date: 2022-08-03 20:06
>> To: draft-yang-teep-usecase-for-cc-in-network@ietf.org <mailto:draft-yang-teep-usecase-for-cc-in-network@ietf.org>; teep-chairs@ietf.org <mailto:teep-chairs@ietf.org>; teep@ietf.org <mailto:teep@ietf.org>
>> Subject: The TEEP WG has placed draft-yang-teep-usecase-for-cc-in-network in state "Call For Adoption By WG Issued"
>>  
>> The TEEP WG has placed draft-yang-teep-usecase-for-cc-in-network in state
>> Call For Adoption By WG Issued (entered by Tirumaleswar Reddy.K)
>>  
>> The document is available at
>> https://datatracker.ietf.org/doc/draft-yang-teep-usecase-for-cc-in-network/ <https://datatracker.ietf.org/doc/draft-yang-teep-usecase-for-cc-in-network/>
>>  
>>  
>>  
>> _______________________________________________
>> TEEP mailing list
>> TEEP@ietf.org <mailto:TEEP@ietf.org>
>> https://www.ietf.org/mailman/listinfo/teep <https://www.ietf.org/mailman/listinfo/teep>
>> 
>> 
>> -- 
>> Daniel Migault
>> Ericsson
> _______________________________________________
> TEEP mailing list
> TEEP@ietf.org
> https://www.ietf.org/mailman/listinfo/teep