[Teep] Re: comments on draft-ietf-teep-usecase-for-cc-in-network-09

[Meiling Chen <[e-mail]>]

Hi Michael,

A：agreed
B：In section 3 declared “The connection between Network User and Network M/OC depends on the implementation of specific network.”, which means this step is not part of teep protocol. 
"Network User requests for confidential computing resource", is for explaining the usecase.
 
In fact from step 1 to step 5 are the specific steps of how to use confidential computing in different environment and hardware architecture. So my personal opinion is to keep these steps for clear description.
 
In case2, the UA and TA are packaged as one package. And the PD is a separate package. The reason to classify the package like section 4 is that different package mode has different remote attestation sequence. In 4.2, the TA and UA are bundled as one package, which means before transfer PD to TA in TEE environment the remote attestation to TA must be executed first. From section 4.1 to 4.5, the steps are all have different load sequences to adapt different package model and different hardware architectures. 
 
C: see the above response.
 
D: the appendix is used to explain submodules in TEEP Agent. The submodules are mainly for providing a middleware or API for TEE hardware. This appendix is only for explanation, the TEEP Agent does not “manage” submodules, it could contains different submodules. 
 
Editorial Nits: thanks for your suggestions, I agree with you.

Best,
Meiling
 
From: Michael Richardson
Date: 2025-05-16 17:12
To: Meiling Chen; teep
Subject: comments on draft-ietf-teep-usecase-for-cc-in-network-09
 
I read draft-ietf-teep-usecase-for-cc-in-network-09 today.
A. The reference [CCC-White-Paper]
         Confidential Computing Consortium, "Confidential
         Computing: Hardware-Based Trusted Execution for
         Applications and Data", January 2021,
         <https://confidentialcomputing.io/white-papers-reports/>.
 
Could point directly at:
   https://confidentialcomputing.io/wp-content/uploads/sites/10/2023/03/CCC_outreach_whitepaper_updated_November_2022.pdf
except that it's likely to be broken by marketing people who don't understand
the Internet.   The /white-papers-reports link felt kind of vague, and I
thought at first that the paper was gone.
That's a terribly formatted white paper... fonts too small, 2/3 of each page blank.
 
B. I liked that the use cases explained the flow, but is it useful to write
   all of the stuff down (like in section 4.1), when the protocols are not specified?
   Like in step 1 "Network User requests for confidential computing resource"
   how is this done?  I think it matters if this is a new protocol needed (a
   gap), or an existing one, or if this is really part of the TEEP protocol?
 
Steps 3,4,5 would seem to be the ordinate TEEP flow, so is it worth repeating
here?
In eample 4.2, 3/4/5 are slightly different, in that the UA/TA are provided
by the user, and there seems to be no PD.  Is that really that different?
Given that no protocol is specified for the transfer, is this really
different?
 
C. I found the tables in Figure 2,3,4,5 to be very busy, and I could't really
gleam any real understanding from them.  Perhaps the critical substantive
difference between the use cases is embedded in the tables, but I'm not
seeing it easily.
 
D. I'm not sure what I'm supposed to understand from the submodule Appendix.
What I got is that if there are more modules, the TEEP Agent will manage them.
 
Editorial Nits:
1. "could" used in abstract... maybe be more definite :-)
2. expand MEC before using it.  I guess: Multi-access Edge Computing.
   s/For example in MEC/For example in a MEC/
3. I have asked for a git(hub), then I could send grammar/typos directly to
   the authors.
 
--
Michael Richardson <[e-mail]>, Sandelman Software Works
-= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*