Re: [Teep] Charter Text

["Hank Chavers" <[e-mail]>]

Hello TEEP members,

On behalf of GlobalPlatform, I can confirm Jeremy’s analysis below with one
correction concerning the specification process.  GlobalPlatform
specifications are open for public review before they are published.  During
the public review period, anyone can download and provide contributions to
the specifications.

The timeline from Public review of the GlobalPlatform OTrP specifications is
expected to be 1Q 2018.  The active editors are contributing to the work.

Let me reiterate that GlobalPlatform is creating an implementation
independent specification including compliance test to verify
interoperability of implementations.  The creation of an apparently similar
specification in IETF will cause market fragmentation and interoperability
challenges.  


(T)Hank(s)

Hank Chavers
Technical Program Manager
GlobalPlatform

O: [phone]
M: [phone]
E: [e-mail] <mailto:[e-mail]> 







Re: [Teep] Charter Text
Jeremy O'Donoghue <[e-mail]> Mon, 30 October 2017 16:59
UTCShow header
<https://mailarchive.ietf.org/arch/msg/teep/iWzbMHkCnvYKMDcMHyyyIRW4Z6Y> 
It is a little difficult to be certain since GlobalPlatform participation is
organised by company, where IETF is individual.

However, based on the GlobalPlatform TEE Spec Working Group roster - this is
the relevant e-mail reflector - I am aware of participants who are also
subscribed to the TEEP list (snapshot of both lists at 16:21 UTC today) who
are operating from e-mail addresses at the following companies (same e-mail
address in all cases).


  *   Qualcomm (myself), ARM, Interceed, Symantec, Solacia (under than name
“Hansol Secure”), Huawei, Oracle

Four of the five authors credited with OTrP draft 4 are on the
GlobalPlatform TEE Spec Working Group e-mail roster. The fifth has just left
his employer and left the GlobalPlatform roster approximately three weeks
ago.

I cannot speak directly on behalf of GlobalPlatform, but as I wrote the
document outlining the approach to be taken in GlobalPlatform, I can share
the following:

- The guiding objective is to be able to implement both OTrP and TMF [1] (an
existing GlobalPlatform remote management specification) using a common TEE
Remote Admin Service
- Where OTrP and TMF are aligned (which is true for most cases) TMF applies
unchanged. Where OTrP differs from TMF, align behaviour as far as possible
and document the differences.
- Document OTrP requirements around the “Bootstrap Domain” (in TMF
terminology this is a Security Domain that is typically instantiated at
device manufacture, and may contain functionality that cannot be created
using TMF commands)
- The following set of work products to be produced:
  - Modification to existing TMF specification to support OTrP
  - Addition to the SC-RAM [2] specification to accommodate and specify the
OTrP agent
  - Write a new document detailing how JSON in OTrP maps to ASN.1 command
set defined in TMF
  - Write a new security layer document (if required) to support OTrP
  - Write a configuration document for OTrP (this is the precursor to
compliance program as it defines the testable set of functionality)
  - Write a new white paper describing OTrP and TMF

The GlobalPlatform working groups are open only to members. Published
specifications are free to download, but reside behind a “click-through”
license. GlobalPlatform is open in the sense that anyone wishing to pay the
appropriate membership fee can participate.

Hope this helps. If more information is needed I believe it would be most
appropriate to reach out to GlobalPlatform directly as I am speaking in a
personal capacity here.

Jeremy

[1]: TMF - https://globalplatform.org/specificationform.asp?fid=7866
[2] : SC-RAM - https://globalplatform.org/specificationform.asp?fid=7706

On 30 Oct 2017, at 16:16, Dave Thaler
<[e-mail]<mailto:[e-mail]>> wrote:

Do we know who from GlobalPlatform is participating in IETF, and vice versa?

Is there a description of the work GlobalPlatform is proposing to do related
to OTrP?

Where can IETF participants find GP’s discussion of OTrP?  Is it an open or
closed forum?

Thanks,
Dave

From: TEEP [mailto:[e-mail]] On Behalf Of Jeremy O'Donoghue
Sent: Friday, September 22, 2017 8:01 AM
To: Wheeler, David M
<[e-mail]<mailto:[e-mail]>>
Cc: Nancy Cam-Winget (ncamwing)
<[e-mail]<mailto:[e-mail]>>;
[e-mail]<mailto:[e-mail]>
Subject: Re: [Teep] Charter Text

Hi Dave,

On 22 Sep 2017, at 15:26, Wheeler, David M
<[e-mail]<mailto:[e-mail]>> wrote:

I understand your perspective and concern (I think, but would like to hear
more). From Intel’s side, we have some issues with “too close”
relationship to GP, because GP’s definition of TEE security ties that
security to trusted boot. I understand that TZ, and even some of Intel’s
TEEs (Android Trusty implementation) require a trusted secure boot in order
to themselves be secure, but Intel also has TEEs that are *completely
separated* from secure boot, and therefore do not require a secure booted
platform to retain security.

You are correct on this point. However, the GP notion of “trusted boot”
allows quite a lot of wiggle room - the essential requirement is that the
mechanism whereby the TEE is instantiated is bound to a secure root of trust
on the SoC or on off-SoC security processor. I don’t know enough about SGX
to be able to say whether it could meet this definition.

Most actual implementations of GP TEEs are bound to the ARM TZ architecture,
so there may well be some bias to that in some of the informative material
around a GP TEE.

However, implementations of most of the specifications e.g. the GP Internal
Core API, Management Framework, OTrP etc. are not bound to that security
definition. Both TMF and the GP approach to OTrP are explicitly designed to
support management of non-GP TEE.

I do recognise that being outside the GP Security definition might pose
commercial difficulties in such an approach.


Too close a relationship to GP will create issues around this definition. We
need greater discussion around this, otherwise, by definition it rejects
certain Intel TEEs (SGX primarily) and then Intel would consider this an
implementation specific definition aligned to TrustZone, and not a general
TEE protocol.

My suspicion is that it also rejects ARM Cortex-M Trustzone for similar
reasons (which I think has some similarities to SGX in its approach)


I think we need to talk more about this. I agree there is a lot of good
stuff in GP that we should leverage.

Are you open to changing some of these core definitions, and working through
the implications of those changes with us? This will separate us somewhat
form GP standards, I think.

I think there is a need to have standards supporting TEEs that are not
rooted in a secure boot style root of trust, and (ideally) for these to
behave similarly from a developer and management perspective to TEEs that
have such a root.

I would have thought that the main effort in such a case would be to define
a system architecture, security requirements and (eventually) a Protection
Profile - this looks a long way from the charter as currently proposed.

I would need to discuss further internally as to whether that is an effort
to which I would be able to contribute.

Best regards
Jeremy


Very interested in your thoughts and perspective.
Thanks,
Dave Wheeler

From: TEEP [mailto:[e-mail]] On Behalf Of Jeremy O'Donoghue
Sent: Friday, September 22, 2017 1:00 AM
To: Nancy Cam-Winget (ncamwing)
<[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Teep] Charter Text

Qualcomm would like to ensure that the charter and proposed deliverables are
properly differentiated from work occurring in GlobalPlatform based on the
OTrP contribution which has been accepted as a GlobalPlatform work item.

Since the proposed charter for teep includes a close relationship with
GlobalPlatform, Qualcomm suggests some alignment between the organisations
to ensure that there is a single, definitive, set of standards defining OTrP
as the best outcome for all participants.

---
Jeremy O’Donoghue                            email:
[e-mail]<mailto:[e-mail]>
Engineer, Principal/Manager                  tel:   [phone]
NFC & Secure Software and Systems




On 22 Sep 2017, at 05:49, Nancy Cam-Winget (ncamwing)
<[e-mail]<mailto:[e-mail]>> wrote:

Thank you all for responding  and for demonstrating there is good support to
move this work along.

It would be good to get discussions started on the current drafts and
milestones as well.

                Nancy

From: TEEP <[e-mail]<mailto:[e-mail]>> on behalf
of "[e-mail]<mailto:[e-mail]>"
<[e-mail]<mailto:[e-mail]>>
Date: Thursday, September 21, 2017 at 7:10 PM
To: Dapeng Liu <[e-mail]<mailto:[e-mail]>>, Lubna
Dajani <[e-mail]<mailto:[e-mail]>>,
"[e-mail]<mailto:[e-mail]>"
<[e-mail]<mailto:[e-mail]>>, teep-bounces
<[e-mail]<mailto:[e-mail]>>, teep
<[e-mail]<mailto:[e-mail]>>, Mingliang Pei
<[e-mail]<mailto:[e-mail]>>,
"Marc.Canel" <[e-mail]<mailto:[e-mail]>>, Richard Parris
<[e-mail]<mailto:[e-mail]>>, Rob
Coombs <[e-mail]<mailto:[e-mail]>>, "qingyang.meng"
<[e-mail]<mailto:[e-mail]>>, Brian
Witten <[e-mail]<mailto:[e-mail]>>,
"[e-mail]<mailto:[e-mail]>"
<[e-mail]<mailto:[e-mail]>>, Nick Cook
<[e-mail]<mailto:[e-mail]>>,
"[e-mail]<mailto:[e-mail]>"
<[e-mail]<mailto:[e-mail]>>, Hannes
Tschofenig <[e-mail]<mailto:[e-mail]>>,
"zhijian.zhang"
<[e-mail]<mailto:[e-mail]>>, 魏茂
军<[e-mail]<mailto:[e-mail]>>, Dominique
Bolignano
<[e-mail]<mailto:[e-mail]>
>, "[e-mail]<mailto:[e-mail]>"
<[e-mail]<mailto:[e-mail]>>, Mike Hendrick
<[e-mail]<mailto:[e-mail]>>, XiaYubin
<[e-mail]<mailto:[e-mail]>>,
"[e-mail]<mailto:[e-mail]>"
<[e-mail]<mailto:[e-mail]>>, "Paczkowski, Lyle
W [CTO]"
<[e-mail]<mailto:[e-mail]>>,
Pengcheng Zou <[e-mail]<mailto:[e-mail]>>,
"[e-mail]<mailto:[e-mail]>"
<[e-mail]<mailto:[e-mail]>>, "philip.attfield"
<[e-mail]<mailto:[e-mail]>>,
"Andrew.Atyeo"
<[e-mail]<mailto:[e-mail]>>, paromix
<[e-mail]<mailto:[e-mail]>>, ppeterkaa
<[e-mail]<mailto:[e-mail]>>,
"[e-mail]<mailto:[e-mail]>"
<[e-mail]<mailto:[e-mail]>>
Subject: Re: [Teep] Charter Text

hi,

 Beijing Laser Tech. support it.thanks.

________________________________
周鹏
CEO
北京雷森科技发展有限公司
Beijing Laser Technology Development CO.,LTD
地址：西直门北大街甲43号金运大厦7层  邮编100044
手机：[phone]
网址：
www.bjleisen.c<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F
%2Fwww.opentsm.cn%2F&data=02%7C01%7Cdthaler%40microsoft.com%7Cb5effd332f214f
f93f0e08d501caca62%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636416892865
103785&sdata=QGZG4LJTJS0hN7R8hvne1U19a83LybyhnnbxQySBYNQ%3D&reserved=0>om

From: Dapeng Liu<mailto:[e-mail]>
Date: 2017-09-13 00:49
To: Lubna Dajani<mailto:[e-mail]>;
ppeterka<mailto:[e-mail]>;
teep-bounces<mailto:[e-mail]>; teep<mailto:[e-mail]>;
Mingliang Pei<mailto:[e-mail]>; Marc
Canel<mailto:[e-mail]>;
[e-mail]<mailto:[e-mail]>; Rob
Coombs<mailto:[e-mail]>;
qingyang.meng<mailto:[e-mail]>;
brian_witten<mailto:[e-mail]>;
[e-mail]<mailto:[e-mail]>; Nick
Cook<mailto:[e-mail]>;
[e-mail]<mailto:[e-mail]>; Hannes
Tschofenig<mailto:[e-mail]>;
zhijian.zhang<mailto:[e-mail]>;
zhoup<mailto:[e-mail]>;
maojun.wei<mailto:[e-mail]>;
dominique.bolignano<mailto:[e-mail]>;
[e-mail]<mailto:[e-mail]>;
[e-mail]<mailto:[e-mail]>;
xiayubin<mailto:[e-mail]>;
sangjin.park<mailto:[e-mail]>; lyle.w.paczkowski<mailto:lyle.
[e-mail]>; Pengcheng Zou<mailto:[e-mail]>;
fmw<mailto:[e-mail]>; philip.attfield<mailto:philip.attfield@seqlabs.
com>; Andrew.Atyeo<mailto:[e-mail]>;
paromix<mailto:[e-mail]>; ppeterkaa<mailto:ppeterkaa@verimatrix.
com>; 成 鹏<mailto:[e-mail]>
Subject: re: [Teep] Charter Text
Hello Nancy,

Thanks!

Actually, there are lots of companies/experts are very interested in the
proposed TEEP work. But they may not familiar with IETF process, I hope they
would getting more active in the list after the long
summer vacation:)

Note: I have copied to all the experts that are interested in TEEP based on
offline discussions.
To all the experts copied in this mail: Please subscribe to TEEP email list
first if you want to reply.   Here is how to subscribe:
https://www.ietf.org/mailman/listinfo/teep<https://na01.safelinks.protection
.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&dat
a=02%7C01%7Cdthaler%40microsoft.com%7Cb5effd332f214ff93f0e08d501caca62%7C72f
988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636416892865113798&sdata=foGdN4f%2FH
SWJzYRrxXq%2Fi5aXMZJgwLQi9kcqu2cjN7M%3D&reserved=0>
<https://www.ietf.org/mailman/listinfo/teep%3Chttps:/na01.safelinks.protecti
on.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&d
ata=02%7C01%7Cdthaler%40microsoft.com%7Cb5effd332f214ff93f0e08d501caca62%7C7
2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636416892865113798&sdata=foGdN4f%2
FHSWJzYRrxXq%2Fi5aXMZJgwLQi9kcqu2cjN7M%3D&reserved=0%3E> 

Thanks,
Max
------------------------------------------------------------------
From:Nancy Cam-Winget (ncamwing)
<[e-mail]<mailto:[e-mail]>>
Send Time:2017年9月12日(星期二) 23:50
To:Lubna Dajani <[e-mail]<mailto:[e-mail]>>; Petr
Peterka <[e-mail]<mailto:[e-mail]>>
Cc:[e-mail]<mailto:[e-mail]> <[e-mail]<mailto:teep@ietf.
org>>
Subject:Re: [Teep] Charter Text

Thank you Lubna and Petr!

Would still like to hear from others and also solicit feedback on the
proposed charter text.

Warm regards,
                Nancy

From: Lubna Dajani <[e-mail]<mailto:[e-mail]>>

Date: Tuesday, September 12, 2017 at 4:40 AM
To: Petr Peterka <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>"
<[e-mail]<mailto:[e-mail]>>,
"[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>

Subject: Re: [Teep] Charter Text

please allow me to echo Petr's responses.
1. Yes
2. Yes
3. Yes
4. Yes
 I am personally very excited to see this WG form and I look forward to
actively contributing to the evolution of this protocol as I have since the
ideation stages of this protocol …

Thank you Nancy, Petr and everyone here…

Lubna
__________________________________________________
Lubna Dajani  I  Allternet Ltd.
@lubnadajani
@futuristasORG
+ 1 201 982 0934<tel:(201)%20982-0934>


Confidentiality Notice: The information contained in this email and any
attachments is intended only for the recipient[s] listed above and may be
privileged and confidential. Any dissemination, copying, or use of or
reliance upon such information by or to anyone other than the recipient[s]
listed above is prohibited. If you have received this message in error,
please notify the sender immediately at the email address above and destroy
any and all copies of this message.

Sent with
Mixmax<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmixm
ax.com%2Fs%2FSjmasx74wNoX3uu2B%3Futm_source%3Dmixmax%26utm_medium%3Demail%26
utm_campaign%3Dsignature_link%26utm_content%3Dsent_with_mixmax&data=02%7C01%
7Cdthaler%40microsoft.com%7Cb5effd332f214ff93f0e08d501caca62%7C72f988bf86f14
1af91ab2d7cd011db47%7C1%7C0%7C636416892865113798&sdata=olYrJvtu8yvXScwR5fcT8
IPl03hxFWkNVOdvTamoB0o%3D&reserved=0>
<http://mixmax%3Chttps//na01.safelinks.protection.outlook.com/?url=https%3A%
2F%2Fmixmax.com%2Fs%2FSjmasx74wNoX3uu2B%3Futm_source%3Dmixmax%26utm_medium%3
Demail%26utm_campaign%3Dsignature_link%26utm_content%3Dsent_with_mixmax&data
=02%7C01%7Cdthaler%40microsoft.com%7Cb5effd332f214ff93f0e08d501caca62%7C72f9
88bf86f141af91ab2d7cd011db47%7C1%7C0%7C636416892865113798&sdata=olYrJvtu8yvX
ScwR5fcT8IPl03hxFWkNVOdvTamoB0o%3D&reserved=0%3E> 


On Thu, Jul 20, 2017 2:48 AM, Petr Peterka
[e-mail]<mailto:[e-mail]> wrote:
Hi Nancy
I think we had a very productive meeting yesterday. Here are my answers to
your questions:

1) Do you understand what TEEP is trying to achieve?
ANSWER: Yes, I do. I’d like to add that the charter may re-emphasize that
the proposed WG is not going to define the TEE or the TAM service themselves
but just the protocol between them.

2) Is this work that should be done in general?
ANSWER: Yes, it should since there are going to be more and more trusted
execution environments (lower case) especially with the proliferation of IoT
devices which will need more security than what they have today.

3) Is this work that should be done in the IETF, or does it belong to
somewhere else?
ANSWER: Since we are trying to define a protocol that is independent of the
different TEE implementations, I believe that IETF is the right home for it.

4) Should we form a WG with given charter to work on this?
ANSWER: Yes, that is my recommendation.

Thanks
          Petr
 <x-msg://13/#m_4019887533134155472_this>
From: TEEP [mailto:[e-mail]<mailto:[e-mail]>] On
Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Thursday, July 20, 2017 11:13 AM
To: [e-mail]<mailto:[e-mail]>
Subject: Re: [Teep] Charter Text

All,
Please provide feedback on the results of yesterday’s side meeting.  In
particular, we’d like to get feedback on whether this the right scope and
if we have captured it appropriately. If it is not, also please comment and
if possible, provide suggestions for improvement.

We would like to continue discussion over email and get consensus around the
2nd week of September so that we can have a path forward.  In particular we
would like to get answers for:

1) Do you understand what TEEP is trying to achieve?
2) Is this work that should be done in general?
3) Is this work that should be done in the IETF, or does it belong to
somewhere else?
4) Should we form a WG with given charter to work on this?

Warm regards,
    Nancy & Tero (TEEP BoF Chairs)

From: TEEP <[e-mail]<mailto:[e-mail]>> on behalf
of Hannes Tschofenig
<[e-mail]<mailto:[e-mail]>>
Date: Wednesday, July 19, 2017 at 5:56 AM
To: "[e-mail]<mailto:[e-mail]>"
<[e-mail]<mailto:[e-mail]>>
Subject: [Teep] Charter Text

Here is the charter text we came up in the side-meeting today.

------




TEEP -- A Protocol for Dynamic Trusted Execution Environment Enablement
Charter

The Trusted Execution Environment (TEE) is a secure area of a processor. The
TEE provides security features, such as isolated execution, integrity of
Trusted Applications along with confidentiality of their assets. In general
terms, the TEE offers an execution space that provides a higher level of
security than a "rich" operating system and more functionality than a secure
element. For example, implementations of the TEE concept have been developed
by ARM, and Intel using the TrustZone and the SGX technology, respectively.

To programmatically install, update, and delete applications running in the
TEE, this protocol runs between a service running within the TEE, a relay
application or service access point on the device's network stack and a
server-side infrastructure that interacts with and optionally maintains the
applications. Some tasks are security sensitive and the server side requires
information about the device characteristics in form of attestation and the
device-side may require information about the server.

Privacy considerations have to be taken into account with authentication
features and attestation.

This working group aims to develop an application layer protocol providing
TEEs with the following functionality,
* lifecycle management of trusted applications, and
* security domain management.

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.

The solution approach must take a wide range of TEE and relevant
technologies into account and will focus on the use of public key
cryptography.

The group will produce the following deliverables. First, an architecture
document describing the involved entities, their relationships, assumptions,
the keying framework and relevant use cases. Second, a solution document
that describes the above-described functionality. The choice of encoding
format(s) will be decided in the working group. The group may document
several attestation technologies considering the different hardware
capabilities, performance, privacy and operational properties.

The group will maintain a close relationship with the GlobalPlatform,
Trusted Computing Group,  and other relevant standards to ensure proper use
of existing TEE-relevant application layer interfaces.

Milestones

Dec 2017     Submit "TEEP Architecture" document as WG item.

Feb 2018     Submit "TEEP Protocol" document as WG item.

July 2018     Submit "TEEP Architecture" to the IESG for publication as an
Informational RFC.

Feb 2019     Submit "TEEP Protocol" to the IESG for publication as a
Proposed Standard.

Additional calendar items:

Nov 2017     IETF #100 Hackathon to work on TEEP protocol prototype
implementations.

Mar 2018     1st interoperability event (at IETF #101).

Jul 2018       2nd interoperability event (at IETF #102).

IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.




_______________________________________________
TEEP mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/teep<https://na01.safelinks.protection
.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&dat
a=02%7C01%7Cdthaler%40microsoft.com%7Cb5effd332f214ff93f0e08d501caca62%7C72f
988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636416892865113798&sdata=foGdN4f%2FH
SWJzYRrxXq%2Fi5aXMZJgwLQi9kcqu2cjN7M%3D&reserved=0>
<https://www.ietf.org/mailman/listinfo/teep%3Chttps:/na01.safelinks.protecti
on.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&d
ata=02%7C01%7Cdthaler%40microsoft.com%7Cb5effd332f214ff93f0e08d501caca62%7C7
2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636416892865113798&sdata=foGdN4f%2
FHSWJzYRrxXq%2Fi5aXMZJgwLQi9kcqu2cjN7M%3D&reserved=0%3E> 

References:
*	Re: [Teep] Charter Text
<https://mailarchive.ietf.org/arch/msg/teep/tdEQzyyExXTd_CgMeBQL5Pp5EHo> 
"Nancy Cam-Winget (ncamwing)" <[e-mail]>
*	Re: [Teep] Charter Text
<https://mailarchive.ietf.org/arch/msg/teep/5chd5AKYB4Rc7zo2Nd8cuvhB5A4> 
Petr Peterka <[e-mail]>
*	Re: [Teep] Charter Text
<https://mailarchive.ietf.org/arch/msg/teep/ZwlpRwkOZ2Ihyk7-kS8a0DXkTfk> 
Lubna Dajani <[e-mail]>
*	Re: [Teep] Charter Text
<https://mailarchive.ietf.org/arch/msg/teep/gsoUM_yHjeMkUDShLHpzK4WaUVk> 
Dapeng Liu <[e-mail]>
*	Re: [Teep] Charter Text
<https://mailarchive.ietf.org/arch/msg/teep/O3-2KO3SnHSH5Y_G_tzmSR87jqI> 
"[e-mail]" <[e-mail]>
*	Re: [Teep] Charter Text
<https://mailarchive.ietf.org/arch/msg/teep/87yldD-U5BNLnIoVDSXJZVKS1W8> 
"Nancy Cam-Winget (ncamwing)" <[e-mail]>
*	Re: [Teep] Charter Text
<https://mailarchive.ietf.org/arch/msg/teep/C8vPLNYT6Giy_V7uPb8A0kIY9R8> 
Jeremy O'Donoghue <[e-mail]>
*	Re: [Teep] Charter Text
<https://mailarchive.ietf.org/arch/msg/teep/A-xP4zOA0BejshUcgH4N6sOpif0> 
"Wheeler, David M" <[e-mail]>
*	Re: [Teep] Charter Text
<https://mailarchive.ietf.org/arch/msg/teep/VCqzSo-XeT4H-Y_hn-_YeMRBBp8> 
Jeremy O'Donoghue <[e-mail]>
*	Re: [Teep] Charter Text
<https://mailarchive.ietf.org/arch/msg/teep/Gwoji1Kd5zyR3UreQufoA2RN6Ak> 
Dave Thaler <[e-mail]>
*	Hide Navigation Bar
<https://mailarchive.ietf.org/arch/msg/teep/iWzbMHkCnvYKMDcMHyyyIRW4Z6Y> 
*	
*	Date
<https://mailarchive.ietf.org/arch/search/?email_list=teep&index=iWzbMHkCnvY
KMDcMHyyyIRW4Z6Y> 
*	
*	
*	Thread
<https://mailarchive.ietf.org/arch/search/?email_list=teep&gbt=1&index=iWzbM
HkCnvYKMDcMHyyyIRW4Z6Y> 
*	
v1.10.13.p1 | Report a Bug <https://tools.ietf.org/tools/ietfdb/newticket>
| By Email <mailto:[e-mail]>