►
From YouTube: IETF108 TEEP 20200727 1100
Description
TEEP session at IETF108
2020/07/27 1100
B
A
A
I
think
it's
the
afternoon
for
most
everyone,
oh
and
late
evening,
for
those
in
asia,
so
you
are
in
the
itf
108
first
session.
Welcome
and
you
are
participating
in
the
trusted
execution,
environment
and
provisioning
or
teep
working
group.
So
this
is
a
formal
ietf
session.
All
of
the
notewell
rules
apply.
A
I
think
most
everyone
has
participated
in
the
past.
So
I'm
just
going
to
note
this
and
not
go
over
it.
For
the
agenda.
Note
that
we
are
using
the
codium
d
to
take
notes.
Do
we
have,
I
forgot
to
also
introduce
brett
jordan.
We
are
trying
the
session
to
have
a
a
secretary.
So
please
welcome
brett
jordan
for
that
we
need
to
have
at
least
one
more
other
note
taker
did
we
have
anybody
volunteer?
A
A
A
A
C
A
A
A
A
Then
after
we'll
have
dave,
provide
us
the
updates
on
the
transport
tape
over
http
draft
as
well
as
the
protocol,
and
then
we
can
call
the
question
if
we
need
to
do
a
second
working
group
call
for
the
transport
one
as
well
as
whether
we're
ready
to
move
forward
to
publication
on
the
architecture.
Draft
oops,
sorry.
A
Akira,
I
don't
know
if
you,
I
noted
you
as
the
presenter
for
the
hackathon
report
and
then
lastly,
we'll
go
through
the
milestones
as
those
need
to
be
updated.
So
with
that
the
agenda
will
be
pretty
full
soren.
I
didn't
see
you
submit
slides
too
so,
given
that
the
agenda
is
full,
I'm
not
sure
we're
gonna
have
time
also,
especially
since
we
don't
have
the
slides
whether
we
can
get
to
that,
but
I've
added
it
just
in
case
to
the
agenda.
A
F
A
F
For
me
all
right,
so
let's
go
ahead
and
get
started,
then
yeah,
okay,
so
one
change
to
this
slide
as
soon
as
the
window
opened.
Yesterday
I
posted
draft007.
This
title
slide
says
draft
o6
for
the
transport.
It's
now
on.
Drafto
7.06
was
what
was
posted
at
the
time
of
the
virtual
interim
meeting
we
had
back
in
april,
so
I
just
wanted
to
let
you
know
that
I'm
presenting
the
deltas
between
six
and
seven
next
slide.
F
Please
all
right!
So
as
a
reminder,
this
draft
has
gone
through
more
than
a
working
group.
Last
call.
So
there
was
a
working
group
last
call
that
started
back
in
before
november.
We
discussed
it
at
ietf,
106.,
oh
wow,
sorry,
draft
106
was
the
last
thing
before
working
group
last
call
was
started.
We
had
a
working
call
that
started
in
february
and
completed
before
the
intro
meeting
that
we
had
in
april.
We
then
in
april
solicited
additional
reviews
after
working
with
glass
call
so
mark
nottingham,
hanas
and
ming
all
sent
in
reviews.
F
F
F
F
Slide.
Okay.
So
let
me
first
talk
about
the
things
that
we
previously
discussed
at
the
april
intro
meeting
and
I
did
what
I
believe
we
discussed
there.
So
the
first
one
we
had
a
discussion
about
that
should
say:
bcp,
56
bis,
that's
a
typo
on
the
slide,
that's
the
one
that
says
how
to
use
http
as
a
transport
for
any
application
protocols
like
us
that
are
doing
it.
What
it
used
to
say
is
that
when
not
called
out
explicitly
in
this
document,
all
implementation
recommendations
in
56
bis
apply
to
here.
F
Okay,
the
other
two
we
discussed
there
have
are
related
to
the
same
text,
and
so
I
put
it
both
in
the
same
slide.
So
one
had
to
do
with
referring
to
rfc
7925,
which
is
about
tls
considerations
for
iot
devices,
and
then
we
had
a
discussion
in
april
about
what
I
should
say
about
why
it
allows
hdp
rather
than
just
requiring
https.
F
We
said
that
well,
that
was
for
constrained
devices
since
there's
already
an
end-to-end
security
protocol
at
the
application
layer
and
so
there's
new
text,
which
is
those
three
paragraphs
or
those
three
sentences.
It's
all
one
paragraph,
but
it's
broken
for
readability
here.
That
explains
both
of
those
two
things
and
again.
F
My
belief
is
that
this
text
is
consistent
with
what
we
already
agreed
on
in
april,
and
so
for
example,
notably,
it
does
not
discuss
the
use
of
http
for
debugging,
because
we
had
a
discussion
of
that
and
decided
to
leave
that
out
of
the
spec
and
only
talk
about
the
constrained
node
issue
as
the
reason
why
it
might
be
allowed.
But
you
can
say
it's
strongly
recommended
that
we
use
https
and
so
again
my
belief
is
this
has
already
been
discussed
and
this
text
captures
the
conclusions
that
we
had
in
the
april
entry
meeting.
F
Okay,
new
issues
that
I'm
going
to
start
walking
through
so
again
mark
nottingham
did
a
review.
Honest,
did
a
review
and
ming
did
a
review
and
I'm
going
to
start
with
harnesses,
because
this
one
is
related
to
the
previous
text.
And
so,
if
you
go
back
one
slide
temporarily
nancy
you
can
see
in
the
in
the
text.
That's
there
the
bottom
paragraph
right
when
https
is
used.
Tls
certificates
must
be
checked
according
to
2818
as
well
as
6125.
F
If
pkix
certificates
are
used
and
then
they
reference
the
other
one
so
go
for
you
can
see
that
6125
reference
is
there
so
go
forward
now.
So
in
harnesses
review
you
can
see
he
suggested
we
actually
reference
6125.
That
was
what
I
just
showed
you.
So
I
took
honest
suggestion
put
that
in
there.
Hopefully,
the
text
is
right.
F
You
tell
me
if
it's
not,
he
had
a
suggestion
to
there's
some
diagrams
that
showed
a
layer
of
teep,
a
layer
of
tip
over
hdp,
which
is
the
transport
and
a
layer
of
hdp,
and
he
suggested
removing
the
middle
layer.
So
you
see
t
over
hdp
as
two
layers.
I
did
not
make
a
change
here
and
the
reason
was
the
point
of
those
diagrams
is
to
explain
the
relationship
between
documentation,
so
http
at
the
bottom
is
in
http
rfcs.
F
F
Number
four
hanus
noted
that,
and
so
this
one
we
will
have
we'll,
have
a
discussion
of
in
the
t
protocol
presentation,
which
is
next,
but
in
the
transport
spec
there
was
a
statement
in
the
in
the
walk
through
of
an
example
right.
So
this
is
already
an
example.
Walk
through
it
says,
here's
a
particular
way
that
the
stuff
might
be
used
and,
of
course,
there
might
be
other
variations,
but
as
walking
through
a
particular
example,
I
had
this
sentence
about
another
variation
that
could
have
occurred
and
hana
said
well.
F
Actually
that
statement
is,
in
his
opinion,
not
correct,
and
since
it's
not
used
in
the
actual
flow,
I
just
removed.
That
sentence
right.
So
we'll
come
back
to
that
issue,
but
this
was
trivial
to
resolve
on
the
transport
spec
by
not
talking
about
a
second
variation
in
the
middle
of
a
first
variation.
So
so
again
we'll
come
back
to
that
in
the
next
presentation.
A
F
F
I
have
the
chat
room
open
as
well
as
your
screen,
so
yeah
yeah
yeah
is
correct
and
so
right
now
it's
following
what
56
bis
says,
although
augmented
by
you
know
harness
and
other
people's
points,
because
about
iot
and
so
on,
and
so
yes,
if
we
think
that
2818
should
be,
I
would
want
say,
mark
nottingham
who's,
the
editor
of
56
bis
into
the
review
to
tell
me
to
remove
2018,
but
that's
why
it's
still
there
again.
It's
trying
to
keep
full
conformance
with
56
bits.
F
You
were
you,
were
you
were
on
the
last
one.
Sorry,
the
the
last
point
was
just
teach.
The
the
the
example
showed
it
terminating
in
204
no
content,
but
the
normative
text
said
it
just
needs
to
end
in
a
2xx
right
and
he
said
well.
We
should
be
explicit
about
if
it
should
end
in
204
or
not,
and
so
I
added
it
should
be
status
204,
so
you're
still
compliant.
If
you
use
the
200
with
no
content,
but
you
should
use
a
204.
F
100
long
list
of
points,
which
is
great,
thank
you,
honest,
so
the
next
one
hanas
added
made
another
specific
suggestion
to
make
text
me
more
explicit.
It
said
if
the
tan,
this
is
again
what
hana
suggested.
If
the
tam
does
not
receive
the
appropriate
content
type
and
accept
header
fields,
it
should
fill
the
request
returning
a
406,
not
acceptable
response,
and
then
it
must
include
a
content
length
header.
I
took
the
first
sentence
it
that
appears
literally,
as
has
suggested.
F
The
second
sentence
I
did
not
include,
and
the
reason
for
that
is
if
it
should
be
a
204
content
length,
is
illegal
with
a204,
and
so
it's
you
know
present
when
you
have
a
body,
but
it's
absent
if
it's
a
204,
no
content
which
must
not
contain
a
body.
So
since
204
is
allowed,
you
can't
say
it
must
include
a
content
length
header
so
that
one
I
didn't
take,
but
the
other
sentence
I
did
take
and
then.
Lastly,
the
text
said
that
the
client
uses
the
accept
header.
F
We
didn't
see
normative
language
there
and
my
response,
for
that
is
whenever
documents
use
it
sends
or
it
inserts
or
whatever
that's
implied
normative
right.
There's
the
rfc
editor
guidance
that
says
you
know
avoid
overuse
of
of
must
and
so
on,
and
so
my
take
is
that
the
text
was
already
normative.
As
is
you
can
see,
there's
the
actual
quote
of
a
sentence,
and
that
is
normative
wording.
Even
though
must
does
not
appear,
and
so
I
did
not
make
any
change
there.
A
B
I
hope
you
can
hear
me
yes,
my
reading
of
the
pcb
is
that
you
need
most
of
those
or
these
excessive
lists
of
headers.
In
the
case
when
you
are
when,
on
the
server
side
on
the
client
side,
they
can
be
confused
with
web
communication,
but
in
our
case
like
this
is
not
like
the
classical
web
browsing
type
of
scenario,
but
it's
something
completely
different.
F
Yeah,
so
I'm
going
to
say
what
hannah
said,
which
will
put
his
comments
in
the
context
there
and
then
I'll
respond
here.
So
hanas
is
talking
about
the
first
bullet
here,
which
is
the
text
is
basically
quoted
in
that
second
bullet
says
the
current
text
says
you
should
have
those
four
headers
as
listed
there
right,
cache
control,
note,
store,
etc
and
hanes's
response
was
well.
He
thinks
that
three
of
those
are
overkill
right,
that
of
the
three
other
than
cash
control.
F
He
said
those
are
overkill
and
that's
what
hanus
was
just
saying.
My
understanding
in
conversations
with
mark
before
and
on
other
drafts
is
that
what
the
concern
is
is
that
somebody
can
trick
a
browser
into
somehow
sending
information
to
that
the
server
would
consider
a
protocol
message
and
have
nefarious
behavior
as
a
result,
and
so
my
understanding
is
that
the
recommendations
are.
F
If
it's
not
meant
to
be
used
in
browsers,
then
you
should
use
these
headers,
which
tells
the
server-
and
you
know
the
client
that
nothing
to
see
here
do
not
use
this
as
a
browser.
If
a
browser
ever
gets
this,
you
should,
you
know,
do
something
not
harmful
and
that's
what
these
headers
are
trying
to
do
is
trying
to
prevent
leakage
into
browsers
for
things
that
are
not
intended
for
browsers
again.
Mark
is
the
most
authoritative
one.
I
would
let
him
answer,
but
that
is
my
understanding
is.
F
F
F
Okay,
next
one
it
has
to
do
with
redirects,
okay
and
so
hannah's
pointed
out.
The
text
currently
says
the
redirects
may
be
automatically
followed.
Okay.
So
how
should
a
developer
decide
whether
it
wants
to
follow
that
may
or
not?
Okay?
Well,
so
what
56
bis
says
is
you
know
a
user
agent
is
allowed
to
automatically
follow
a
redirect
right.
F
So
that
text
says
well
honest,
is
right
right
that
it
doesn't
explicitly
specify
the
circumstances
when
it's
required,
and
so
we
weren't
doing
the
right
thing.
Thank
you
hanus
for
pointing
that
out
and
so
there's
a
couple
cases
to
think
about
that.
56
bis
mentions
right.
What
do
you
want
the
case
to
be
when
say
a
proxy
requires
redirection
right.
It
redirects
you,
the
proxy
you
have
to
log
in
or
something
like
that.
F
What
would
you
expect
the
behavior
to
be,
and
the
second
one
is
what
happens
if
the
server
goes
through
some
permanent
change
and
moves,
say
the
path
or
something
that's
going
to
be
listening
on?
What
would
we
want
the
right
thing
to
be
okay,
and
so
I
believe
this
one
is
still
open
that
I
haven't
done
a
change
this,
because
I
wanted
to
ask
the
working
group.
Probably
the
simplest
thing
to
do
is
to
say
that
redirects
must
not
be
followed
automatically
followed
again.
This
is
about
automatic.
F
You
know,
without
user
intervention,
okay,
you
just
automatically
do
it,
and
probably
the
simplest
thing
to
do
is
to
say
you
must
not
do
this,
and
that
just
says
those
two
cases
there
won't
work
without
human
intervention,
okay.
Otherwise
we
have
to
explicitly
come
up
with
one
of
the
cases
that
we
want
to
have
happiness.
That's
what
I
wanted
to
ask
the
working
group.
F
Would
people
be
okay
with
saying
redirects
must
not
be
automatically
followed
or
the
people
say
think
that
there's
some
case
where
we
want
to
have
circumstances
where
we
do
think
it
would
be
acceptable
as
a
may
to
automatically
follow
redirects
and
again
56
bits
is
not
going
to
answer
it
56.
This
says
we
get
to
decide.
F
F
F
G
That
way
dave.
So
my
question
is
so
if,
if
I
don't
think
I
object
to
must
not
unless
configured,
but
I'm
I'm
concerned
here
that
you
said
the
word
user
a
couple
times
in
this
discussion
and
I
don't
know
how
users
would
ever
actually
be
intelligently
informed
about
that
to
be
able
to
make
a
decision.
So
I
think
so
I
I
don't
understand
that
over
how
that
override
would
work.
F
All
right,
let
me
answer
that,
but
you
are
your
assumptions
are
correct,
that
this
is
about
automatic
following
right,
as
opposed
to
some
other
human
intervention.
An
example
of
human
intervention
is,
let's
say,
your
whole
tea
flow
was
triggered
by
a
user
installing
an
untrusted
app
from
an
app
store,
and
so
it's
the
app
store
installer
that
kicks
off
the
thing
that
says
my
untrusted
app
has
a
manifest.
That
requires
this
tab
installed
and
that's
what
kicks
off
the
whole
deep
flow,
so
you're
in
the
context
of
user
flow.
F
G
I
I
don't
I
don't
that
doesn't
feel
like
a
very
good
way
to
do
things
to
me,
and
so
I
was
not
mentioned
anything
in
the
text
about
users
so
well.
The
the
issue
is:
if
we
don't
automatically
redirect-
and
we
don't
redirect
into
in
particular
cases
that
we
would
enumerate,
then
it
seems
like
we
never
redirect
unless
there's
some
override
and
I'm
difficulty
understanding
what
that
override
could
possibly
be,
and
so
what
I'm
reading
is
we
never
wrote.
We
never
redirect.
F
So
I
believe
in
practice,
that
is
a
fair
assumption
that
if
we
change
they
must
not
and
practice
that
there
will
never
be
any
redirects
followed.
And
so,
if
say,
the
server
uri
ever
changes
it's
up
to
the
tam
to
configure
the
tp
or
somebody
to
send
out
a
new
manifest
or
whatever.
It
is
to
to
configure
it
some
way
because
you're
not
going
to
get
it
through
hcp
through
an
hp
redirect
all
right.
And
similarly,
if
you're,
ever
behind
an
authenticated
proxy.
F
F
Okay,
this
one
actually
overlaps
with
the
architecture
document,
and
so,
if
I
take
two
minutes
on
this
one,
it's
taking
it
out
of
the
other
time
because
there's
a
corresponding
slide
near
their
deck,
it's
whichever
one
we
got
you
first,
there
was
a
suggestion
from
hanas
that
section
three,
which
talks
about
the
broker
architecture,
okay
and
there's
an
example
of
the
picture.
That's
in
that
section.
This
is
the
one
that
talks
about
how
the
line
between
what
goes
inside
the
te
and
what
goes
outside.
F
In
most
cases,
it's
a
left
line
a,
and
so
this
section
here
is
more
about
the
whole
relationship
of
how
the
things
fit
together
and
the
protocol
architecture
than
it
is
about
the
transport,
so
hana
suggested
taking
this
section
in
entirety
or
almost
entirely,
because
the
last
part
of
the
last
paragraph
of
this
section
is
actually
about
the
transport
by
taking
most
of
this
section,
just
moving
it
to
the
architecture
document,
I
actually
agree
with
hannus,
and
so
in
the
architecture
document
presentation.
We
think
it's
done.
F
This
is
the
only
remaining
issue
on
the
architecture
document
that
the
editors
don't
think
has
been
resolved,
and
so
I
think,
and
apparently
hanas
thinks
and
now
ming
thinks
that
it's
fine
to
move
this
section,
which
everybody's
already
reviewed,
because
it's
been
through
working
group
last
call
but
to
move
it
from
one
dock
to
the
other
dock,
where
there's
already
a
broker
section,
but
it
doesn't
have
this
level
of
detail,
and
so
we
move
it.
Presumably,
underneath
that
same
section,
it's
already
in
the
architecture
document
just
moving
some
content
again,
the
editors.
F
F
Okay,
if
I
don't
hear
anything
else,
you
can
go
on,
but
again
that
was
two
minutes
out
of
the
architecture
document
since
I
covered
this
first
I
see
ming
is
on
now,
so
I
guess
I've
covered
that
one
so
yeah
go
on.
Let's
see
what
do
I
have
left
I'll,
try
to
zip
through
the
rest,
but
that
was
two
minutes
of
ming's
time.
Go
ahead,
nancy!
F
F
So
that
was
the
thing
that
was
arguable
as
to
whether
it
was
editorial
or
not,
and
so
since
that
was
the
original
intent,
it
was
not
really
editorial,
but
it
could
be
read
as
being
a
normative
change,
so
hopefully,
for
the
better.
The
last
one,
which
is
probably
a
larger
issue
to
get
consensus
on
here,
is
the
the
scoping
so
particularly
there's
some
phrase
there
that
appears
in
the
abstract
in
the
introduction.
F
Now
it
talks
about
that
the
scope
of
the
protocol
is
update
code
and
data
in
a
tee,
which
I
think
is
correct,
but
ming
suggested
narrowing
that
to
say,
the
scope
of
the
t
protocol
is
to
update
tas
and
data
in
a
dee,
okay
and
so
there's
a
key
difference
here,
which
I
will
explain
my
opinion
on
that
the
t
protocol
depends
on
rats
for
attestation
and
suit
for
manifest
to
install
things.
Okay,
and
so,
although
the
the
things
that
you
request
say
you
know,
I
need
to
install
such
and
such
a
ta.
F
The
suit
manifests
include
dependencies
and
you
can
have
depend,
manifested
depend
on
other
manifest,
whether
they're,
embedded
or
severed
or
whatever,
and
so
that
means
that
a
suit
manifest
can
install
not
just
a
ta,
but
it
can
express
how
to
install
any
dependencies.
Well.
Dependencies
from
a
ta
could
include
other
tas.
It
could
include
a
trusted
os
like
opti.
F
And
so
my
opinion
is
this
would
be
natural
in
both
rats
and
suit.
Where
rats
you
have
the
attestation
the
whole
platform
up
through,
maybe
the
ta
or
the
cheap
agent,
as
well
as
suit
manifest
to
install
not
just
tas,
but
at
tas
and
their
dependencies,
and
in
my
opinion
it
would
be
very
unnatural
to
say
sorry,
you
can
only
include
suit
manifest
that
don't
go
down
below
tas
right.
F
That
would
be
very
odd
to
me
and
rule
out
things
that
would
otherwise
be
natural
and
in
my
opinion
it
would
incent
people
to
use
protocols
other
than
teeth
and
would
use
rats
and
suit
with
these
other
dependencies.
And
so
my
opinion
is.
The
text
is
correct,
that
it
says
code
and
data
in
a
tee,
it's
just
tas
and
their
dependencies.
But
if
people
have
other
opinions,
please
bring
them
up
now,
because
I
don't
know
if
ming
has
another
opinion,
but
that's
my
rationale.
So
we
want
an
explicit
working
group
consensus
on
this.
A
H
A
I
F
F
A
So
it
it
sounds
like
we
did
and
we'll
go
over
and
confirm
this
on
the
mail
too,
and
and
as
we
go
through
the
milestone,
so
I'd
forgotten
that
you'd
had
the
second
that
we
had.
The
second
working
group
last
call.
So
the
only
action
that
I
noted
is
that
we
just
need
to
confirm
with
mark
that,
yes,
indeed,
everything
is
still
okay,
we
may
be
ready,
barring
your
your
next
set
of
updates
to
go
to
publication.
Is
that
correct.
F
That
is
my
belief
unless
you're
right
so
there's
two
notes
that
I
have
one
is
to
change
that
may
to
a
must,
not
for
the
redirects.
The
other
one
is
to
move
section
three.
Those
are
the
two
pending
changes
that
I
would
have
and
then,
after
that,
my
belief
is
that
we
are
done
and
have
addressed
all
comments
again.
I
want
to
confirm
that
we've
addressed
ming's
comment,
but
that
was
that
last
point
that
we
were
having
but
yeah.
F
A
A
F
And
again,
you're
welcome
to
call
time
on
me
this
time
if
you
want,
since
I
ate
up
some
of
my
own
time
here,
so
this
is
the
protocol
spec,
which
has
not
gone
through
working
group.
Last
call
that's
why
this
one
was
at
the
end
after
the
other
two
which
have
gone
through
last
call
so
t
protocol
03
in
progress.
So
next
slide.
F
Okay,
all
right,
so
the
reminder
of
the
timeline
on
this
one.
Oh
one
was
discussed
at
the
virtual
interim
meeting.
We
had
a
bunch
of
discussion
there
shortly
thereafter.
O2
was
posted
to
address
things
that
were
discussed
there,
which
covered
about
16
pull
requests
that
were
open
at
the
time.
Draft
03
was
posted
just
after
the
suit
hackathon,
the
suit
hackathon.
F
I
I
at
least
was
working
on
use
of
suit
in
teep,
and
so
I
posted
draft
03,
which
included
four
pull
requests,
resulted
from
learnings
during
the
suit
hackathon
in
july,
the
virtual
hackathon
that
happened
what
two
weeks
ago,
and
so
in
particular
the
most
notable
thing
was
something
that
could
break
interoperability,
and
so
it
turned
out.
There
was
a
contradiction
in
the
spec
between
the
success
message
and
error
message.
F
F
F
So
again,
I've
separated
these
things
related
to
deep
architecture.
Things
created
a
suit
manifest
and
the
things
only
related
to
this
document,
and
if
we
don't
get
to
those,
then
we
get
we
call
time.
So
these
are
the
ones
relevant
to
the
architecture
document.
Okay,
so
in
here
we
have
there's
two
issues:
here's
what
the
architecture
document
currently
says.
Okay,
it
says
that-
and
this
is
in
the
information
that
is
passed
from
the
agent
to
the
tam
okay.
F
So
it
says
you
pass
like
a
list
of
requested
components
which
say:
here's
a
list
of
zero
or
more
say
tas
or
things
that
are
requested.
So
let's
say
you
had
an
untrusted
app.
That
depends
on
a
particular
ta
and
it
wants
to
be
installed.
They
can't
really
succeed
without
this
ta,
and
so
you
pass
this.
I
need
such
and
such
a
ta
and
that
gets
passed
up
to
the
tam
to
decide
whether
it
wants
to
grant
that
or
reject
it
or
whatever.
So
that's
what
the
architecture
document
is
talking
about
here.
F
Okay,
there's
two
ways:
you
could,
in
theory,
pass
that
information.
You
can
pass
those
in
attestation
claims,
in
other
words
inside
the
body
of,
say,
an
eat,
and
this
is
actually
what
the
architecture
document
says
now
or
you
could
pass
those
in
a
separate
query:
query
response
field,
okay
and
so
the
heap
protocol.
Since
I
don't
know,
we've
explicitly
asked
this
question,
but
if,
for
any
reason
we
were
to
change
from
a
to
b,
it
would
affect
the
architecture
document.
F
That
is
my
assumption
of
what
we've
talked
about
before,
but
I
just
wanted
to
track
that
this
was
that
issue
that
the
t
protocol
document
does
not
currently
say
anything
about
this.
Nor
does
it
define
any
explicit
claim,
and
so
you
can't
actually
implement
this
yet
until
you
actually
have
a
specific
claim
defined.
Okay.
So
that
way
I
could
not
implement
this
yet,
but
he
says
this
is
architecture
says
we
need
to
do
this
and
that's
why
this
is
still
open.
F
Just
checking
all
right
so
unless
there's
any
objections,
this
is
a
track
that
still
needs
to
be
done
and
the
default
answer
is
a
because
it
does
not
require
changing
anything
in
the
arc
dock,
and
so
in
the
past,
we've
had
a
discussion
about
any
type.
Specific
claims
that
are
relevant
to
rat
would
be
defined
in
the
teeth,
working
group
and
reviewed
by
the
rats
working
group.
I
believe
that
was
our
previous
agreement,
but
there's
no
draft
that
does
that
yet,
but
I
believe
that
was
the
previous
agreement
between
teep
and
rats.
F
Slide,
okay,
so
the
next
question
had
to
do
with
something
that
is
not
discussed
in
either
place.
So
this
one
you
remember.
Let's
say
you
had
a
ta
that
was
installed
because
an
untrusted
app
depended
on
it.
Okay,
now
you
want
to
uninstall
the
untrusted
app
okay,
that
removes
the
last
reference
of
anything
that
would
ever
call
into
that
ta.
F
What
do
you
do?
Is
there
a
way
to
remove
the
ta?
Well,
certainly,
the
tam
can
always
choose
to
remove
an
eta,
but
does
the
tam
know
that
there's
no
nothing
that
would
ever
call
into
it
anymore?
How
does
it
know
that
right
now,
there's
no
way
for
it
to
know,
and
so
on.
Some
te
architectures
like
sjs
right,
an
untrusted
installer
can
just
delete
a
file
right.
F
Some
you
can
just
delete
the
file,
but
on
others
right,
you
can't
you
don't
have
permissions
to
because
maybe
it's
stored
in
some
place,
you
can't
touch
unless
you're
inside
they
say
a
deep
agent,
so
only
the
tam
can
actually
clean
up
that
ta,
and
so
that
means
that
if
you
have
no
way
to
inform
the
tam,
only
the
team
can
delete
it.
Then
you
end
up
with
these
unused
tas.
It's
just
consuming
space.
F
The
tam
doesn't
even
know
about,
doesn't
know
that
it's
not
used,
and
so
there's
no
discussion
anyplace
about
this
notion
of
maybe
you'd
want
to
pass
a
list
of
unneeded
tas
to
attain
not
just
requested
ones,
and
so
the
question
the
working
group
is.
Should
we
support
this
scenario
of
passing
a
list
of
no
longer
needed
tas
to
the
tank,
just
like
requested
tas
again
the
terms
authoritative?
F
Is
there
a
way
to
pass
a
hint
and
again
the
possible
answers
that
I
know
of
are
yes,
we
should
add
another
attestation
claim
that
can
express
that,
or
maybe
it's
part
of
the
same
claim
in
another
field
or
something
but
the
attestation
claims
b
via
separate
query
response
field
and
again
a
and
b
in
my
opinion
would
be
consistent
with
the
choices
of
a
or
b
on
the
previous
slide
or
the
current
answer.
No,
and
if
the
answer
is
not
no,
then
do
we
need
a
bullet
in
the
architecture
document.
F
F
Are
there
any
objections
to
going
through
a
to
say
that
requested,
tas
and
and
no
longer
requested
or
requested
that
they
have
no
longer
are,
should
be
symmetric
and
be
covered
the
same
way
in
any
documents?
Let's
see,
I
see
russ
plus
one
hanus
and
somebody
who
I
don't
know
their
name,
because
I
can't
read
you
sorry,
a
might
be
good
and
hanus
asked.
Do
we
really
need
to
change
the
architecture
document?
Technically,
I
would
say
no.
F
Although
the
architecture
document
does
have
an
implied
list
of
requirements
for
claims
and
if
we
think
that
this
would
be
done
via
a
then
it's
probably
easiest,
especially
for
moving
section
three
and
touching
the
architecture
document
anyway,
akira
says:
maybe
a
both
a
or
b
are
tough
to
implementing
yep
fair
enough.
Okay,
so
it
looks
like
I
see
emerging
consensus
and
nobody
in
the
chat
anyway
objecting,
and
so
if
anybody
has
an
objection
to
a
please
call
it
out.
F
Otherwise,
when
I
propose
a
pull
request
for
moving
section
three
for
harness
request
and
from
transport
to
architecture,
I
would
also
add
a
sentence
or
a
phrase
about
this
one.
At
the
same
time,
okay,
okay,
thank
you
sucasa.
Thank
you
all
right
next
slide.
Please
thank
you
for
giving
me
the
pronunciation
of
okay
all
right
so
now
I
know
brendan
you're
on
the
call
here's
issues
related
to
you,
issues
related
to
manifest
next
slide.
F
Okay,
so,
as
I
was
trying
to
implement
this,
the
first
question
has
actually
come
up
in
a
meeting,
and
I
can't
remember
if
it
was
the
team
meeting
of
the
suit
meeting.
I
think
it
was
the
steep
meeting
where
brennan
was
presenting
before
and
it
had
to
do
with
the
notion
of
templates.
Maybe
it
was
in
the
suit
meeting
right.
The
suit
manifest
document
has
a
number
of
templates
for
how
you
might
accomplish
various
things.
F
The
first
example
would
be
one
where
a
ta
and
a
te
are
largely
synonymous
like
sgx
and
there's
no
notion
of
a
security
domain
or
the
ability
to
enumerate,
and
so
on
so
sgx
or
anything.
That's
like
sgx,
where
you
know
there's
you
don't
have
to
have
any
sd
step,
there's
not
even
an
implicit
one.
It's
just
automatically
one
to
one.
Second
example
is
I've
already
got
a
security
domain,
it's
a
global
platform
compliance
security
domain
and
I
want
to
install
a
ta
into
into
one
that
already
exists.
F
Okay
and
the
third
example
would
be.
I
want
to
install
a
ta
into
a
brand
new
security
domain
that
gets
created
right.
It's
implicit
or
explicit.
The
template,
or
example,
would
show
that
and
and
have
that
mentioned
as
to
whether
it's
explicit
or
implicit,
okay,
and
maybe
one
or
two
of
these
could
be
combined,
but
I
think
these
are
three
kind
of
cases
to
cover
now
that
we
use
a
suit
manifest
right.
The
only
all
all
these
things
are
just
down
inside
the
suit
manifest
and
as
creation
of
a
security
domain.
F
I
guess
the
net,
the
most
the
most
similar
example
might
be
in
a
suit
manifest.
If
you
were
trying
to
copy
a
file
into
a
path
that
didn't
exist
until
you
created
the
directory,
would
you
want
a
create
directory
command
or
is
creating
the
path
implicit
when
you
try
to
copy
into
that
path?
That
would
be
the
natural
thing
and,
if
brandon,
if
you
have
any
comment
on
that,
okay,
good
I'll,
stop
and
let
brennan
talk,
go
ahead.
J
Okay,
so
when
it
comes
to
creating
security
domains,
what
makes
sense
to
me
is
that
they
should
be
lazily
instantiated.
I
don't
see
a
reason
to
instantiate
one
before
you
have
a
ta
to
put
into
it.
Unless
someone
can
give
me
a
counter
example,
and
so
I
think
that's
probably
the
right
answer
and
once
you've
got
a
security
domain.
Installing
a
new
ta
into
an
existing
security
domain
again
looks
to
me,
like
lazy
instantiation,
solves
that
in
exactly
the
same
way
as
the
the
previous.
J
So
if
it's
already
there,
you
can
install
directly
into
it
by
using
path,
scoping
you're
able
to
make
sure
that
you
can
define
acls
for
exactly
who
has
rights
over
what
and
if
those
acls
are
implicit
in
teep.
That's
completely
fine,
so
I
think
it
all
sort
of
fits
in,
and
we
did
actually
discuss
this
at
the
suit
virtual
interim.
F
F
J
F
Probably
the
key
protocols
back
with
the
answer,
but
my
so
there's
a
meta
question
here
about
whether
the
examples
and
the
template,
if
there's
a
template,
whether
that
belongs,
whether
we
put
that
into
the
teat
protocol
spec
or
under
the
suit
manifest
spec
with
the
other
templates
right
now,
my
net
my
opinion
as
a
suit
coach
here,
is
we're
trying
to
be
done
with
a
suit
manifest.
So
we
either
put
it
in
now
and
be
done
if
it's
really
easy.
F
J
J
F
Okay
and
the
part
that
I
skipped
on
this
slide
is
between
those
three
examples.
There's
also
the
two
different
cases
when
a
ta
binary
comes
with
a
tam
and
then
there's
the
case
of
when
a
ta
binary
is
already
on
the
device,
and
you
just
need
the
metadata.
I
think
akira
or
somebody
else
followed
an
issue
specifically
on
this,
which
I
think
I
have
on
the
next
slide.
So
so
this
other
case
about
how
do
I
put
in
this
commands
to
install
when
the
binary
is
already
resident
on
the
machine.
So.
J
That
should
okay
there's
a
couple
of
different
approaches
to
that
one
of
them
is:
it
exists
in
a
different
component
id,
in
which
case
you
can
copy
it
in
and
that's
fine.
The
other
is
that
you
need
a
lazy
fetch
and
when
I
say
a
lazy
fetch,
what
I
mean
is
that
it
needs
to
take
the
digest
which
is
available
to
the
the
fetcher
as
well
as
the
url
and
say
I
already
have
this
digest.
Therefore,
I
don't
need
to
do
a
fetch.
F
J
F
We
can
show
two
examples:
there,
the
a
is
just
a
natural
one,
using
suit
manifest
and
and
b,
when
it's
already
a
resident,
we'll
use
that
in
like
a
specific
example,
maybe
with
component
ids
with
like,
like
you
mentioned
or
whatever
so,
okay,
that
sounds
like
sufficient
direction
to
do
it.
A
a
a
proposed
text
here
for
people
to
review
with
the
next
version,
so
yeah
thanks
brandon,.
F
Yeah
keep
going
so
now
we're
now
we're
past
the
ones
that
affect
any
doctor
now
and
the
ones
that
are
only
this
document.
Okay,
so
here's
one
that
issue
number
13..
I
don't
remember
who
filed
this
one
filed
it,
and
so
the
observation
was
that
you
know:
can
it
be
the
question?
The
issue
is
something
like:
can
it
be
used
with
sgx,
I
think
was
the
name
of
the
the
title
of
the
issue,
and
so
sgx
already
has
its
own
intel
specified
evidence
format
right,
it's
not
rat's
eat
it's
one!
F
That's
already
shipping
and
using
people
use
it
now
right.
Rats
eat
is
still
under
still
under
specification,
and
so
sgx
is
already
in
use
for
their
evidence,
format
and
so
the
rats
architecture
discusses.
You
know
multiple
evidence
formats
that
come
into
a
verifier
as
an
example.
The
verifier
might
then
use
a
standard
format
for
sciatic
station
results,
so
the
rewind
party
only
knows
one,
but
the
verifier
has
to
deal
with
the
heterogeneity.
F
F
F
Here's
the
other
format
id
option
b
is
to
say
no,
no,
no,
we
are
only
going
to
support
eats
and
if
you
got
something
else,
you
have
to
find
a
way
to
wrap
it
in
each
and
then
your
evidence,
format
just
gets
bigger
and
you
need
two
parsers
okay
and
then
c
is
sorry.
No
we're
not
going
to
support
that
we're
going
to
use
an
eat
and
only
an
eat
and
sorry,
if
you
don't
like
that,
go
away.
Okay,
that
would
be
c
and
so
which
direction
should
we
take
with
the
cheap
protocol?
F
Is
my
question
for
the
working
hana
says
depends
on
whether
people
want
to
use
teep
for
sgx?
I
would
say
my
opinion.
Yes,
the
opinion
for
whoever
filed.
It
is
probably
yes-
and
I
assume
I
don't
know
if
david
wheeler's
on
here,
but
I
assume
he's
he's
on
the
architecture
document
as
a
co-author,
because
he
wants
the
answer
to
be
yes,
so
hannah
says
I
would
go
for
a,
and
I
see
somebody
else
b
or
a
my
own
opinion
myself.
F
F
F
Okay,
then
I'm
going
to
propose
that
as
the
author
a
looks
good,
okay,
so
fine,
so
the
next
verse
in
the
document.
Again
it
has
not
the
last
call
or
anything.
So
you
get
a
chance
to
review
this
later
is
we'll
take
a
shot
at
doing
a
in
the
document
and
see
if
people
like
that,
so
okay.
So
I
think
at
this
point
you're
going
to
call
time
on
me
and
that's
fine
to
stop
nowadays.
F
H
Cool,
so
we
have
a
lot
of
group
called:
let's
call
it
eighth
version
and
we
could
receive
reviews
from
ross
and
danielle
and
tyrion,
and
so
on
and
many
from
russ
and
daniel
have
a
long
list
of
reviews.
It's
a
very
good
feedback
and
we
have
three
revisions
since
then.
I
have
a
9
to
12
and
that
in
next
I'm
going
through
the
issue
list
that
we
filed.
According
to
the
comments
given
by
russ
and
daniel
yeah
next
slide.
H
So
totally
we
filed
with
part
of
the
issues
most
of
russian
ones
that
translate
into
individual
ones,
and
if
that
is
the
one
we
catch
up
and
we
put
into
one
issue
at
201
and
the
rest
of
the
issue
is
the
most
we
captured
in
170
285,
that's
16
issues,
so
next
I'm
going
through
each
one's,
not
all
of
them
right.
I
just
selected
one.
So
I
don't
go
through
all
that
all
the
ones
someone
said
just
skip
when
it's
a
tutorial.
H
F
A
F
Okay,
so
here
the
comment
was
to
add
some
examples:
to
illustrate
security
operations
and
sensitive
data
by
a
ta,
and
so
we
added
these
two
examples
like
a
banking
application
and
credit
card
numbers,
and
so
that's
so
that's
the
actual
text
that
was
added
so
for
sticking
about
30
seconds
per
slide.
We
can
leave
that
up
for
a
second
here.
I
F
F
Next,
let's
stare
at
this
one,
I'm
not
as
fast
as
this
one
as
ming.
So
let's
see
revising
the
definition
of
ca.
There
was
the
old
text,
the
new
text,
the
c8
is
an
entity.
You
can
see
the
previous
one,
it
didn't
say
you
know
what
a
ca
was
right.
It
just
talked
about
other
things
without
explicitly
saying
that
that
what
the
ca
was,
and
so
the
definition
is
actually
a
ca-
is
an
entity
that
issues
and
so
on.
So
that
was
cleaning
up
that
definition.
Next.
F
F
H
Yeah,
I
have
network
issues
and
I'll
come
back
okay,
so
this
is
that
integration.
Yes,
this
also
says
support
both
the
competition
integrity
protection.
There's
a
wording
missing
there.
So
the
old
context
of
the
ssr
preserved
confidentiality
of
sensor
data
there
and
we
changed
at
the
preserved
confidentiality
and
added
and
support
the
integrated
protection
that
will
change
and
the
rust
was
good.
At
that
time
you
may
change.
H
So
this
was
a
key
transfer
agreement.
This
one
says
what
initially
says
equipped
with
time
publicly
directly.
I
think
that
was
not
com,
not
accurate.
It's
a
it's!
A
public
key
user
wrapper
and
station
key
right
key
equipment,
so
the
contact
will
change,
says
below
it
says
very
important.
Particular
I
just
said
a
content
is
a
encrypted
with
a
key
that
is
established
with
a
content
encrypted
key.
H
F
A
F
One
I'll
just
make,
I
didn't
I'll
just
try
to
finish
what
he
was
saying,
but
we
tried
to
make
russ's
comment
here
and
correct
the
text,
and
so
you
can
see
the
new
text
on
the
bottom.
That
addresses
russ's
comment
about
what
was
incorrect
right,
that
it
doesn't
encrypt
it
with
the
tam
public
key
and
encrypt
it
with
the
key
created
from
the
damn
public
key
or
you
know,
established
with
the
tampa
key,
and
so
the
new
text
should
be
saying
that
so
yep.
That
makes
sense.
F
Next
slide:
okay,
there
was
a
discussion
about
raw
public
key.
An
earlier
document
didn't
mention
this,
but
there
was
a
couple
places
that
were
still
missing
the
similar
text,
and
so
it
still
talked
about
certificates,
and
so,
if
you're,
using
raw
public
keys
rather
than
certificates,
we
tried
to
touch
any
remaining
places
like
this
one.
You
can
see
it
must
obtain
a
10
certificate
or
the
raw
public
key
of
a
town,
and
so
what
goes
in
your
trust,
anchor
store.
F
F
Discussion
about
a
certificate
that
never
expires,
okay,
and
so
there
was,
we
should
add
a
sentence
because
there's
a
reference
that
I
think
russ
pointed
out.
Here's
a
place
that
our
existing
rfc
that
talks
about
how
to
do
certificates
that
don't
expire
or
considerations
around
recommendations
around
what
to
do,
and
so
we
added
that
particular
text
to
reference
the
specific
section
that
rest
pointed
out.
F
Okay,
let's
see
this
one
is
long
discussion
to
cover
compromise
trust
anchor.
So
rosa's
comment
was:
please
expand
this
discussion
to
cover
compromise
trust,
anchors
and
compromised
intermediate
cas,
so
we
added
in
those
sentences
to
talk
about
this
and
since
we've
only
got
about
30
seconds
per
slide
I'll
leave
it
up
there
for
a
second
here,
as
people
want
to
scan
through
it
in
case
there's
something
that
jumps
out
at
you
that
you
want
to
talk
about,
because
I
don't
know
what
to
highlight
here.
What
ming
was
going
to
highlight.
F
I
don't
think
that
russ
has
commented
since
we
addressed
it
so,
okay,
again
russ.
If
this
doesn't
look
good
to
you,
please
let
us
know
the
editors
believe
that
this
does
what
you
were
looking
for.
A
discussion
compromised
trust
anchors
and
compromised
cas,
not
just
intermediate
case.
We
covered
intermediate
and
in
theory
root
case,
but
that's.
F
F
Look
so
you
can
review
it
offline
if
you
need
to
so
yeah
yeah,
you
don't
have
to
give
us
an
answer
in
30
seconds.
So
all
right,
let's
go
on
to
the
next
slide,
all
right.
So
now
we're
on
to
the
last
parts,
which
is
daniel's
comments.
Most
of
his
comments
were
editorial,
and
so
those
are
done,
and
so
there's
only
a
couple
things
to
talk
about
here
we
fixed
tam
in
one
place
probably
doesn't
need
to
be
highlighted
there
device
definition.
F
There
was
this
place
where
it
talked
about
trust
anchors
in
a
device
that
was
confusing
trust
anchors
or
in
you
know,
the
deep
agent.
So
there
was
this
table
of
where
keys
are
stored,
and
now
it
always
tries
to
match
that
and
doesn't
have
any
this
generic
hand
wavy
text
before
so
those
are
pretty
easy.
Next.
F
Okay,
so
the
use
case
daniel
commented,
it's
unclear
whether
this
is
a
single
use
case
for
many
use
cases.
I'd
like
to
have
more
okay,
in
particular,
I'm
gonna
highlight
the
party
says.
Typically,
it
seems
that
the
ui
is
part
of
the
ta
which
guarantee
trusted
inputs,
and
he
talks
about.
It
seems
important
to
consider
that
anything
coming
out
of
the
untrusted
world
can
be
tampered
or
replayed,
even
the
output
of
a
ta.
F
Your
pin
input
might
be
a
trusted
peripheral,
that's
only
accessible
to
the
te
right.
That
would
be
a
a
very
typical
global
platform.
Implementation
on
a
payment
terminal-
and
we
extended
that
to
say
input
or
a
trusted
display
so
that
the
ree
cannot
observe
or
tamper
with
the
user
input
or
output
right.
So,
for
example,
in
such
a
payment
terminal,
you
might
have
it
wired
such
that
the
little
lcd
display
is
also
only
accessible
to
the
tee
and
that
the
re
can't
you
know
take
take
over
messages
or
view
anything
that
you
put
on
there.
F
You
could
do
that
too,
so
that's
an
or
so
it's
not
normative
or
anything,
but
it
does
try
to
cover
that
the
outputs
can
be
trusted
or
trustable
in
something
like
a
global
platform
architecture.
So
in
other
words,
this
use
case
talks
about
not
just
input
but
also
output.
So
that
was
the
resolution
of
daniel's
comments
or
daniel's
comment
on
this
one.
So
next
slide.
F
Is
such
a
request,
a
teep
request
or
something
more
abstract,
and
so
now
he
said
when
the
t
broker
receives
a
request,
see
the
request
ta
api.
So
it's
actually
not
a
t
request.
It's
referring
to
an
abstract
api
call.
That's
defined
later
in
that
same
document.
It's
not.
We
just
added
a
forward.
Reference
may
be
explicit,
so
it's
neither
a
teep
request
per
se.
It's
nor
something
more
abs.
Maybe
it's
more
abstract!
It's
an
api
call.
So
next.
H
H
I
know
you
could
okay,
so
this
is
this
one,
so
this
one,
this
comment
was
just
anchor
started
in
in
the
te
and
suggest
that
that
one
should
be
in
agent.
I
believe
this
one
so
agency
already
preliminary,
but
not
that
to
that
network
expect.
So
what
we
changed
here
is
particularly
point
out.
The
just
anchor
trusted
times
provision
in
the
t
agent
predict
target
agent
and
not
just
generally
the
device
itself.
So
this
is
a
quick
fix
and
it's
straightforward.
So
next.
H
One
okay,
so
this
one's
about
arrows.
So
I
think
then
the
comments.
Could
you
want
to
talk
about
the
meanings
of
arrows?
It's
a
who's
who
points
to
it's
a
it's.
A
gate
like
a
top
city
will
add
error
now
say:
gate
is
a
wizard
which
is
started,
who's
who's
the
source
was
destination.
Then
we
changed
below
now
indicate
particular
fixes
like
in
store,
right
supply
to
apple
developer,
to
app
store
and
then
for
apple
store
to
device.
What's
install
now
say
who
initiated
that
one?
H
We
know
it's
from
device,
go
to
download
from
app
store
and
then
install
then,
when
sitting
in
store,
then
look
at
who
initiated
what
we
now
add
explicit
sentence
says
arrow
indicates
the
direction
of
data
transfer.
It
doesn't
mean
that
who's
the
actor
who's
who
is
being
changed.
So
it's
a
just
purely
indicate
where
the
data
flows
from
where
to
where
so
to
clarify
that.
H
F
David,
do
you
mind
finishing
since
yeah
daniel
mentioned?
I
also
believe
that
some
additional
considerations
are
needed
for
regarding
tenants
sharing
a
given
device,
and
so
we
added
in-
and
we
added
in
some
other
text
about
that.
So,
for
example,
you
know
ta
might
be
able
to
escape
from
malware
detection
or
access
other
tas
if
a
t
provides
isolation
between
tas,
and
so
it's
talking
about
what
you
know
to
motivating
we're
removing
of
a
malicious
ta.
And
so
I
don't
know
what
I'll
say
about
that
one.
F
A
I
I
I
I
F
This
is
dave
as
far
as
for
me,
everything
that
was
my
learnings.
I
talked
about
in
the
other
two
presentations
and
so
yeah.
I
progress
in
my
implementation,
at
least
for
some
things,
and
I
kept
notes
about
what
issues
I
was
running
into
and
that's
what
I
already
presented
so
yep
making
progress.
So
it's
just
the
implementation
sides
of
what
I
presented
with
the
doc
issues.
B
Hi
yeah,
I
I
made
some
progress,
but
not
as
much
as
I
was
hoping,
I'm
still
on
track
for
the
encrypted
da
binaries,
which
I
hope
I
can
then
contribute
to
the
to
the
list
and
then
maybe
as
examples
to
the
draft
as
well.
So
that's
that's
still
my
plan,
but
got
quite
far
already
not
so
much
during
the
one
day,
upwards
yeah.
I
Next
and
that's
okay,
so
now
I
worked
with
yuji,
I'm
a
colleague,
so
that's
project
is
a
taman
tea
pageant
using
suit
manifest.
So
what
we
plant
is
that
adding
certain
implementation
to
cheap
implementations
so
ut,
I
have
developed
the
tip
device
size
and
I
have
developed
deep
server
sites.
So
in
this
action
we
plan
to
add
the
support
of
suit
for
our
deep
implementations.
I
I
I
I
First
one
is
tip
devices
deep
device
and
that
is
developed
by
iced
and
aquila
and
and
the
other
implementations
are
dave.
Swann
and
hannes
swan
and
uit
provides
leave
deep.
That
is
a
c
library
and
you
can
try
from
that.
Url
and
the
other
side
is
a
gif
server
thumb
server.
So
that
is
a
also
divs
and
harness
have
a
con.
I
I
A
E
E
We've
been
working
on
this
for
more
than
a
year
pro
honestly,
it's
more
than
two
years,
but
we
never
open
up
the
source
code,
anything
so
the
person
who
was
in
the
hackathon
that
was
in
the
same
table
or
something
that
only
knew
what
we
were
doing.
So
this
is
something
I'm
try.
I
would
like
to
explain
what
is
what
we've
been
doing?
E
Initially,
we
did
a
initial
prototyping
on
that
board,
more
specifically
96
sports,
and
then
we
heavily
customized
that
initial
implementation
on
on
the
opt
in
aisd,
so
changing
the
data
board
or
running
on
other
update
was
all
completely
was
very
difficult,
so
we
started
with
finally,
after
the
hackathon
in
this
february
in
berlin,
we.
Finally,
we
started
to
generalize
our
implementation,
general
q,
healthy
on
qmu,
and
that
that
was
really
a
big
big
job.
E
It
wasn't
really
going
to
help
the
tip
of
implementation
directly,
but
we
had
to
make
it
more
something
generic,
so
we
could
move
on
and
then
we
are
moving
to
porting
on
risk.
Five,
not
on
any
hardware
or
just
just
on
qmu
right
now,
we
do
have
a
board,
but
first
we
want
to
run
it
on
the
qmu,
and
so
that's
the
entire
story
of
what
we've
been
doing
and
right
side
is
the
picture
of
the
deep
architecture,
a
slightly
easier
way
to
understand
on
arm
and
risk
five
risk.
E
E
Something
it's
similar
on
risk
five.
So
next
page
next
page,
please,
yes,
and
for
so
this
is
the
implementation.
We've
been
genera
generalizing
from
some
of
the
features
we've
been
removing
from
what
we
watch,
which
does
not
relate
to
deep
in
our
initial
prototype,
something
we
had
our
own
trusted
blue
or
secure
boot.
So
this
is
the
tip
broker
deep
agent,
and
example,
hello,
app
and
hello,
ta
pair
and
and
to
test
with
our
tpa
tip
device.
E
E
Risk
five
has
few
favorite
label,
the
highest
level
is
n
mode,
and
second
level
is
s
mode,
so
normally
linux,
kernel
or
any
operating
system
will
be
running
on
s
mode
and
your
application
will
be
running
on
m
mode.
A
u
mode
and
right
now
it's
in
the
middle
of
defining
and
implementing
h
mode,
which
is
for
a
hypervisor
mode.
E
But
at
this
time
we're
not
using
h
mode
and
on
the
right
side,
is
the
trusted
world
and
there's
already
keystone
project
for
providing
te
a
program
environment
for
the
risk
5
from
uc
berkeley.
So
we
using
keystone
infrastructure
and
adding
global
platform
like
api,
it's
honestly
a
subset
of
the
global
platform
api.
The
reason
we're
using
global
platform.
Api
wrapper
on
top
of
the
keystone
is
make
it
easier
to
port
the
application
on
da
from.
E
We
were
also
using
libweb
circuit
for
the
http
handling
and
also
initially,
we
were
doing
json
handling
and
holds
the
handling,
so
we've
been
using
it,
but
it's
bit
over
good
for
just
handling
http
right
now,
but
right
now
we're
just
using
it
as
it
is,
and
the
embed
tier
this
is
doesn't
have
to
be
embedded.
This
could
be
open,
sso
or
anything,
but
it's
using
a
similar
make
file
from
inside
the
te
side.
E
Five
still
have
a
link
error,
but
what
was
really
we
helped
having
a
gp
api
wrapper
was
really
help
because
we're
only
able
to
successfully
able
to
build
in
about
two
weeks.
If,
if
we
didn't
have
a
global
platform
api
like
a
wrapper,
then
it
will
be
taking
much
longer
and
the
other
side
is
still
working
on
it
on
the
linux
side,
yes,
and
that's
for
page
finish
for
page
nine,
yes
and
yeah,
all
the
people
who
contributed
on
the
hackathon
and
implementation.
A
A
What
I
wanted
to
go
through
is
we
need
to
update
our
milestones
because
we're
a
little
lagging
okay,
we
may
be
a
lot
lagging,
and
so
what
I've
noted
here
on
the
left
hand
side
when
you
look
at
in
our
tracker.
These
are
the
old
dates
and
so
we're
actually
doing.
Okay,
we're
we're
running
somewhat
behind,
as
I
suspect,
given
that
we
still
have
to
discuss
more
on
the
open
issues
for
the
protocol.
A
F
Yeah,
it's
certainly
not
gonna
august.
You
can
see
that
I
didn't
actually
make
it
to
the
end
of
the
open
issue,
slides
correct,
but
there
are
some
things
we
have
not
had
a
chance
to
discuss
as
a
working
group
which
we
can
move
to
the
list.
But
the
point
is
that
we're
not
going
to
be
ready
for
working
class
call
in
august
november
is:
okay,
that's
still
aggressive,
but
it's
still
movie
doable.
F
A
F
A
F
Right
there
was
two
things
that
I
observed
on
the
architecture
document.
One
was
moving
section
three,
which
is
text.
That's
already
been
through.
A
working
group
last
call
he's
moving
it
from
one
doc
to
another
doc.
So
hopefully
that
is
hard
to
break
and
then
the
other
one
was
potentially
a
phrase
about
the
requested,
tas
and
also
tas-
that
are
no
longer
needed
and
just
adding
a
couple
words
in
there.
You
know
and
such
and
such
in
another
sentence
there.
So
those
are
the
two
things
that
I
noted.
F
A
F
F
A
A
So
I'm
going
to
let
dido
speak
for
this
too,
because
I
think
he
actually
looked
at
this
draft
also
deeper
than
I
did,
and
the
question
for
the
authors
is
similar
to
the
architecture
you
needed
to
do
a
couple
more
updates
there.
We
need
to
confirm
with
mark
that
everything
is
is
still
okay,
and
so
the
question
is,
I
can
put
it
back
to
september,
given
those
updates.
C
F
F
It
needs
another
update
just
for
some
trivial
things
which
we've
already
discussed,
but
I
think
both
docs
are
basically
in
the
same
state
as
I
already
have
been
through
we're
working
with
last
call
and
just
addressing
things
now.
If
mark
comes
back
and
says
hey,
you
know
somebody's
right,
you
should
change
the
such
and
such
texture
on
headers.
That
would
change
things,
but
right
now
my
assumption
is
that
mark
is
still
just
as
good
as
he
always
has
been,
and
it's
in
the
same
state
as
the
architecture
documents.
A
B
I
was
just
wondering
like
whether
we
really
need
to
be
so
aggressive
on
the
on
the
transport.
I
think
I'm
fine
with
completing
the
architecture
as
soon
as
possible,
because
we
already
have
been
working
it
for
a
while,
but
the
transport
like
if
it
gets
done
in
in
a
few
months
later,
let's
say
november,
it
would
equally
be
fine.
By
that
time
we
we
got
all
the
at
least
the
protocol
issues
sorted
out
and
if
there's
any
spillover
into
transport,
then
then
we
know
what
I
would
like
to
avoid.
B
A
F
Yeah,
I
don't
have
a
strong
opinion,
but
my
opinion
of
saying
it's
red
is
based
on
the
fact
that
it
was
originally
written
for
otrp,
which
was
farther
along
in
terms
of
you,
know,
implementations
and
things,
and
so
we
know
the
work
for
that
and
we
just
ported
it
over
to
there,
and
so,
since
we
already
have
full
implementations
of
it.
Unlike
the
t
protocol,
I'm
just
explaining
why
I
think
it's
unlikely
to
change.
Is
it
possible
sure
just
like
we
could
find
some
issue
with
hdp?
It's
just
very
unlikely.