►
From YouTube: TEEP WG Interim Meeting, 2020-11-19
Description
TEEP WG Interim Meeting, 2020-11-19
C
B
B
The
example
case
we're
gonna
walk
through
is
where
you
have
an
untrusted
app
that
has
a
dependency
on
trusted,
app,
a
okay
that
trusted
app
a
comes
from
tam,
a
and
say
in
the
untrusted
manifest
that
has
the
ta
a's
identifier
and
the
tami's
uri
okay,
now
internally,
that
is
expressed
in
a
suit
manifest
and
that
suit
manifest
depends
on
a
different
trusted
component,
meaning
a
different
suit,
manifest
that
different
suit
manifest
and
this
example
is
hosted
by
tam,
b.
Okay.
B
This
might
be,
for
example,
because
tam
b
is
the
ta
developer
and
the
trusted
component
b
might
have
say
a
personalization
data
that
contains
a
private
key
necessary
to
decrypt
a
that
would
be
an
example,
okay,
and
so
that's
why,
in
the
architecture
document
and
previous
discussions,
we've
said
these
two
things
could
be
from
two
different
tams,
and
so
here
the
suit
manifest
for
a
depends
on
the
suit
manifest
for
b.
Okay.
B
So
that's
the
example:
we're
gonna
walk
through
four
different
potential
approaches
that
we
could
take,
although
one
and
two
are
very
similar,
okay,
so
option
one
works
as
follows:
right
the
agent
sends
out
a
query
request
and
just
as
a
reminder,
the
query
request
happens
by
the
agent
opening
up
an
http
connection
to
tam
a
that
has
empty
content.
It's
the
first
message
which
comes
in
that
http
response.
That's
current
request.
B
The
agent
says:
hey,
I
need
a
okay,
so
in
this
example,
either
here
or
maybe
a
priori
tem
a
would
have
to
reach
out
to
10
b
and
go
and
fetch
or
download
the
content.
That's
the
the
bundle
with
the
suit
manifest
for
for
bundle
b,
okay,
and
so
what
protocol
is
this?
That's
why
it's
a
dashed
line
here?
B
It's
not
necessarily
the
t
protocol,
maybe
it's
https
or
something,
but
the
question
is
well
what,
if
tam
b
only
wants
to
release
that
to
an
authorized
entity
that
attests
and
so
that's
a
whole
bunch
of
extra
work
that
would
be
necessary
there
and
so
that
one's
very
complicated
it
might
be
doable.
But
it's
very
complicated.
B
So
here
the
difficulty
is:
what
does
this
fetch
b
thing,
especially
when
b
needs
the
courier
to
a
test,
and
in
this
case
part
of
the
point
is
tam
a
is
not
trusted
by
either
for
for
the
content
of
b,
and
so
how
do
we
solve
that
complicated
but
potentially
doable?
If
you
want
to
do
eventual
work?
Okay,
so
that's
option
one
option
two
is
very
similar.
B
The
only
difference
in
option
two
is
that
the
install
messages
are
on
two
different
messages
right,
and
so
you
install
each
dependency
success
and
then,
finally,
you
install
the
dependent
a,
but
otherwise
it's
the
same
thing.
Okay
option
number
three
works
like
this:
okay
here
so
remember
here
the
dependency
resolution,
one
and
two
is
done
by
the
tam
a
now.
This
has
to
fetch
all
the
dependencies,
so
it
can
push
all
the
installs
down.
B
The
agent
is
only
talking
to
the
the
top
level
tam
you,
the
one
that
actually
that
the
ua
actually
depends
on
okay,
unlike
those
option,
three
puts
the
dependency
resolution
inside
the
agent
okay,
so
my
understanding
is
the
suit
manifest
actually
allows
this,
and
that's
why
this
one
is
my
preferred
out
of
the
four.
This
is
one
I
like
the
best
okay
and
this
one
works
as
follows:
right
career
request,
hey,
I
need
a
that
part's,
the
same
tame,
a
just
says:
okay,
here's
a
here's,
some
dangling
dependencies.
B
It
depends
on
b
and
here's
the
uri
for
b,
and
so
that's
expressed
in
the
suit
manifest
that
has
this
dependency
on
this
thing
that
has
to
be
resolved.
Okay,
and
so
at
this
point
the
agent
can't
complete
that
install
right
because
it
needs
the
dependencies
before
it
can
install
a,
but
it
has
the
tan
b's
uri,
because
it
was
in
that
suit,
manifest
okay,
and
so
it
has
to
reach
out
to
tam
b.
That
says:
hey
I
need
to
resolve
a
dependency
10
b
sends
a
query
request.
Saying
please
attest
to
me.
B
B
B
The
manifest
is
sent
inside
the
install
message
right:
okay,
okay,
so
this
install
a
has
the
suit
manifest
for
a
which
includes.
You
know
the
binary,
if
that's
bundled
with
the
with
the
manifest,
includes
the
metadata
for
a
which
includes
all
the
list
of
dependencies,
if
any,
which
in
this
case
would
include
the
information
necessary
to
resolve
b.
Okay.
So
here
the
disadvantage
of
a
is
just
that
there
can
be
a
significant
delay
between
the
install
and
the
success
of
to
that's
in
response
to
that
install
okay.
B
So
in
some
sense,
if
a
if
the
tam
is
trying
to
keep
steep,
then
he
sends
this
install
and
potentially
never
hear
us
back
for
a
while
right.
What
if
this
was
a
took
a
long
time
to
download
or
just
took
a
long
time
to
reach
or
whatever
there
could
be
a
significant
delay
in
between
here.
Okay
again,
this
is
still
my
favorite
option
out
of
these,
but
that
is
the
disadvantage.
B
C
B
C
B
B
B
A
B
B
He
described
it
for
a
different
case
and
the
one
that
I'm
walking
through,
but
in
the
example
that
I'm
walking
through,
then
you
might
say
you
know
I'm
working
on
it.
So
it's
not
a
success.
It's
not
an
error.
We
have
to
define
a
brand
new
message
for
this.
That
says:
okay
working
on
it
just
to
let
you
know
and
then
at
the
end
you
have
to
send
back
a
success
to
send
back
the
success
either
unsolicited.
B
By
unsolicited
I
mean
when
you
first
open
the
http
connection.
Instead
of
a
zero
byte
post,
that
gets
a
query
request.
It
could
be
a
post
that
just
has
the
success
in
it
and
in
that
case
it's
unsolicited,
and
this
gets
into
that
question
with
the
discussion
we
were
having
about
token
yesterday,
because
the
install
echoes
back
the
token
in
in
here
the
in
progress
and
so
what
token
to
use
here.
Do
you
reuse
the
token
or,
what's
that
some
of
the
complexity
there,
or
do
you
generate
a
new
message
here?
B
B
A
Let's
do
this
option
three
right,
let's
say
imagine
example:
application
ad
depends
on
non-personal.
Data
depends
on
10
or
100
other
types,
ps
yep.
Then
this
process
takes
long
right.
Do
we
need
to
handle
that
case?
It
almost
puts
this
and
dependencies.
You
finish
depending
it
takes
15
minutes
finish
right,
then
your
install
a
to
successor
a
will
not
work.
That's
the
line
well,.
B
The
same
thing
can
happen
if
you
have
zero
dependencies,
if
you
just
have
a
really
complicated
install
that
just
takes
15
minutes
because
you're
on
a
constrained
device
and
you've
got
to
do
a
bunch
of
operations
that
depend
on
maybe
resources
being
available
that
might
take
a
while
to
be
available
and
so
on.
You
might
need
this.
You
might
take
15
minutes
even
with
no
dependencies.
A
So
now,
let's
just
separate
yourself:
it's
a
do.
We
treat
as
let's
use
http
as
a
practical
example
right
here,
so
we
do
it.
It's
a
even
in
store
a
and
successfully
that's
a
two
http
transactions.
They're,
not
the
same
transaction.
We'll
talk
about
here,
mobilization
token
expiration
right,
not
the
individual,
http
transaction
right,
because
we
said
it's
a
queries,
but
in
stock
a
is
a
it's
a
it's
interesting!
It's
a
it's
actually
requested.
It's
always
initiated
from
agents
right
agent,
reach
out
time,
a
yeah,
so.
F
A
B
A
Right,
we
need
to
ensure
the
token
whatever
that
station,
what
have
stations
transaction
id?
Let's
say
that
way.
Install
air
well
expect
a
token
and
then
transaction
id
back
say
just
that
transaction
done.
As
long
as
I
have
a
longer
expiration
time
window,
this
can
work.
It
doesn't
need
to
acknowledge
it.
It
doesn't
have
heartbeat
of
acknowledgement.
So
I'm
working
on
I'm
working
out
right
option
for
someone
about
heartbeat
acknowledgement.
A
B
Yeah
right,
I'm
gonna
go
back
just
to
respond
to
you
to
the
slide
that
we
had
that
we
covered
yesterday,
which
is
this
one
which
is
pending
the
discussion
that
we
will
have
in
suit
at
the
suit
working
group
that
it
is
possible
that
we
may
not
actually
need
a
token
for
install
and
delete,
and
so
there
may
be
no
need
to
keep
state
on
the
tam.
With
a
token.
So
that
depends
on
what
the
resolution
is
for
suits.
So.
B
A
A
A
B
D
D
B
D
A
The
manifesto
file
is
a
described
dependency
sparked
with
the
application
itself.
It
doesn't
depend
on
which
transaction
right
that
is
unique
in
that
way,
but
it's
a
another
unique
based
on
like
in
the
morning
and
send
it
send
the
install
command
where's
the
afternoon
install
command.
Those
two
commands
should
be
different.
It.
C
D
So
if
you
send
the
same
command
a
second
time
and
you
have
a
dangling
reference
to
the
the
first
one
that
hasn't
been
closed
and
you
get
a
record
of
a
report
back
that
says,
I
have
installed
this
image
or
you
know
this
manifest
well.
The
result
of
installing
this
manifest
is
both
of
those
previous
dangling
commands
can
now
be
cloaked.
B
A
The
matter
right
so
yeah,
like
first
command,
do
second
one
may
become
a
evenly
installed
from
client.
It
explained
as
a
reinstall
right
first
worked.
Second
install
is
maybe
reinstalled
or
it
in
the
water
decline,
so
that
actually
has
different
interpretation.
So
I
also
feel
that
anytime,
you
do
a
device
update
web
application.
Installation
should
have
unique
transaction
id.
B
A
question
to
brendan
because
the
suit
manifest
defines
the
was
it
the
the
update
procedure,
if
I'm
using
the
right
term
capital?
U
update
capital
p.
I
think
it's
update
procedure.
Okay,
if
you
already
have
a
particular
suit,
manifest
with
a
particular
digest
installed
and
you
initiate
the
update
procedure
a
second
time.
D
The
suit
report
should
contain
exactly
the
same
content
as
if
it
were
installed,
each
of
the
checks
will
result.
In
the
same
result,
each
of
the
you
might
get
a
different
result
code
for
a
fetch
like
it
might
say.
I've
already
got
that
rather
than
I
got
that.
Okay,
I'm
I
I'm
not
so
far.
We
have
left
that
as
an
application
or
an
implementation
dependent
detail,
but
it
certainly
wouldn't
be
a
failure.
B
And
if
it
is,
you
know
if
the
fetch
had
a
different
result.
Wouldn't
that
be
the
same
as
if
you
pre-cached
the
binary
and
with
the
you
know,
in
other
words,
the
the
binary
was
pointed
to
by
the
manifest,
but
the
binary
wasn't
in
bundled
into
the
manifest,
and
if
you
already
had
the
binary
cache
locally,
isn't,
wouldn't
you
get
the
same
result
in
that
case,
the
first
time?
B
Yes,
it's
verifying,
okay,
so
yeah
that
thank
you
for
verifying
my
understanding.
So
my
belief,
then,
is
that
the
token
shouldn't
matter,
in
other
words,
even
if
you
were
to
reorder
the
two
and
respond
with
you
know,
if
you
were
to
flip
the
successes
in
the
reverse
direction
and
match
them
with
the
opposite
ones,
you'd
end
up
with
exactly
the
same
result.
B
H
Much
I
would
like
to
comment
on
I
I
should
have
made
notes,
so
the
delay
was
a
little
bit
vast.
I
have
to
highlight
so.
First
of
all,
there
was
this
sequencing
question.
Could
you
go
back
to
one
of
the
interactions
like
option
three,
for
example,
this
resolves
a
interaction
between
team.
A
and
tempe
leaves
everything
to
agent.
H
I
I
still
think
there
might,
if
you,
if
you're
going
with
evidence
and
such
there
might
still
be
a
relationship
between
a
and
b,
because
I
am
not
entire,
because
tem
b
now
has
to
understand
what
is
depending
on
it,
when
there
is
a
request
coming
that
when
this
is
this
thing
initiated
from
agent.
That
is
not
highlighted
here.
I
think,
and
then
tempe
has
to
request
evidence
now,
and
it
doesn't
know
why
it
doesn't
know
that
tam
a
has
some
done
something
and
provided
probably
also
at
the
station
requests.
H
H
So
it
is
surprised
by
this,
maybe
and
and
why,
by
the
concatenated
thing
from
option,
one
or
two
is-
is
somehow
mitigating
that
problem,
because
tem
a
could
now
provide
that
information
to
me
it
is
actually
more
fragile,
because
agent,
I
think,
is
a
chaining
and
therefore,
if
tem
a10b
stuff
fails.
How
does
agent
the
agent
know
about
this?
That
is
like
tab.
A
has
to
inform
agent,
like
my
dependency
failed.
That
is
more
complicated,
more
complex.
So,
in
this
options
three
and
four
are
better.
H
B
Gotcha,
so
let
me
respond
to
that,
so
let,
before
I
get
into
b
for
a
second,
let's
talk
about
tam,
a
okay
when
so
the
the
way
that
this
works
is
query.
Request
would
include
the
challenge.
So,
if
you're
using
nonces
right,
then
this
is
where
the
nonce
would
appear
and
the
e
will
appear
in
query
and
query.
B
So
I'm
just
I'm
going
to
say
what
a
is
and
then
I'm
going
to
say
how
it's
the
same
for
b.
So
in
a
the
same
message
that
carries
the
evidence
also
carries
the
fact
that
it
need
that
it's
asking
for
a
but
what
it
does
not
pass.
The
tam
a
in
the
current
protocol
is,
it
does
not
identify
which
untrusted
app
is
expressing
a
dependency
on
a
okay.
B
It's
not
something
would
normally
be
in
the
evidence
unless
we
start
specifying
it
in
rats,
and
it's
not
something.
That's
the
t
message.
So
what
that
means
is
tam
a
is
making
a
decision
purely
based
on
the
fact
that
the
agent
says
that
it
has
a
need
for
a
and
the
team
can
decide
whether
to
grant
that
request
or
not,
regardless
of
who's
depending
on
it.
Okay.
B
It
could
have
been
that
this
that
the
untrusted
app
had
a
dependency
on
b
right,
if
that
was
the
case,
tim
b,
wouldn't
know
which
untrusted
app
at
least
today,
and
therefore
it
does
not
need
to
know
at
least
that's
the
current
claim,
which
he,
the
fact
that
it's
a
you
know,
taa.
That
depends
on
b,
because
it
didn't
know
that
an
untrusted
apple,
that's
not
part
of
the
requirements
right
now,
and
so
here
what
happens?
Is
that
the
reaches
out
to
tam
b
and
10
b
doesn't
know
why?
B
Yet
so
it
sends
a
query
request.
What's
your
state,
and
why
are
you
asking
me,
okay
and
the
response,
the
agent
attests
with
his
evidence
and
says,
and
I'm
talking
to
you,
because
I
need
b,
apparently,
okay
and
then
tam
b
can
decide
whether
to
grant
that
wish
or
not.
So
the
point
is
that
tam
b
is
doing
the
same
thing
as
tam
a
where
the
thing
that
you're
worried
about
is
not
currently
requiring
the
protocol.
You
don't
care
what
the
dependent,
what
the
dependent
piece.
B
H
Okay:
okay,
in
this
case,
all
the
decisions-
why
something
is
not
working
in
this
option?
Three
or
four
even
is
better,
because
yeah
the
agent
has
total
control
of
about
completeness.
It
might
be
interesting
to
have
this
aliveness
feature.
I
have
no
strong
opinions
of
what
is
unless
it's,
if
it
doesn't
scale.
Well,
if
you
do
that,
a
lot
right.
B
Right
right,
my
I
have
two
goals
that
I'm
attempting
to
optimize
simultaneously
and
maybe
at
odds
sometimes,
but
I'm
hoping
not
one
is
that
I
would
like
the
agent
to
be
able
to
scale
down
to
a
constrained
device
and
number
two.
I
would
like
an
ultra
scalable
tam
that
ideally
has
zero
state
or,
as
close
to
zero
state,
is
at
me
zero
state
between
http
requests
as
possible.
B
E
C
I
D
B
B
Tambi,
it's
not
that
easy.
No,
the
evidence
itself.
If
you
inside
the
rats
architecture,
you
have
to
ensure
that
that
evidence
is
fresh
okay.
So
the
notion
of
the
challenge
is
to
say,
if
you're
using
nonces,
which
is
the
way
that
eats
were
first
defined,
it
might
not
be
the
only
option.
But
nonsense
is
like
the
thing
that
we
usually
talk
about.
D
B
Nonsense:
okay,
which
requires
an
extra
round
trip
to
go
and
fetch
the
nonce,
but
hey
you
know
the
teat
protocol.
Has
this
query
request
step
that
kind
of
has
that
extra
thing
which
I
would
like
to
get
rid
of
in
cases
where
you
don't
need
it?
The
second
option
is
synchronize
clocks,
and
so
that
one
requires
time
stamps,
but
it
requires
that
you
have
a
clock
and
that
that's
actually
synchronized
with
a
trusted
time
source.
B
H
Yeah,
I
can
add
to
this
that
this
both
solutions,
synchronization
of
clocks
or
distribution
of
handles,
requires
extra
effort.
It's
as
easy
as
that,
and
so
there
might
be
scenarios
where
this
is
unavoidable,
but
then
architectural
advice,
it's
also
doable.
The
evidence
conveyed
can
change
appraisal.
Evidence
is
not
defined
here.
So
so
you
can
add
that
on,
but
without
it
you
cannot.
Do
this
fair
relaying
of
evidence
by
still
claiming
it's
fresh.
D
H
That
is
a
handy
distribution.
Thingy
like
you,
can
you
can
do
it's
a
hybrid
of
handle
and
clock.
You
can,
of
course,
with
every
request
for
evidence.
You
can
butterfly
keep
a
fresh
timestamp
from
a
timestamp
server
that
that's
how
tuda
works
effectively
the
time-based
unidirectionalization,
and
then
you
can
relay
evidence
as
long
as
you
will
want
for
the
feasibility
of
the
timestamp
token,
and
so
that
that's
fine,
of
course.
Also,
but
it's
again
it's
it's.
A
Say
something
yeah?
I
would
like
to
add
the
comments.
I
just
said
this
model
was
option.
Three
in
general
are
favor
options
for
reason.
Think
about
the
chaining
dependency
right.
If
the
a
depends
b
b
depends
c.
So
if
his
option
two
will
be
collect
c
and
count
back
to
a
because
I
don't
want
to
scale.
If
I
let
it
divide,
the
agent
handle
that
right,
800
dependency
is
equal
to
a
go.
To
b.
Equal
to
c
depends
on
that.
If
you
have
chain
dependency,
it
can
go
further.
G
A
C
C
B
Ming's
point
is
that
if
you
have
a
tree
of
stuff,
you
know
a
depends
on
b
depends
on
c
a
depends
on
d.
If
they
involve
different
tams,
that
means
you
have
to
go
out
and
collect
all
of
the
nonces
and
stuff
send
them
down
to
the
agent.
So
you
now
have
a
whole
bunch
of
nonsense.
You
need
to
include
either
in
your
evidence
or
evidence,
sets
somehow
to
be
able
to
pass
back.
That's
the
complexity.
Is
it
solvable?
A
B
C
H
C
A
A
B
B
F
Yes,
so
from
from
the
what
I
learned
from
the
hackathon
option,
one
and
two
difference
between
one
and
two
and
three
or
four,
is
how
much
the
cheap
message
format
gets
simpler
or
not
and
making
the
time
as
much
as
possible
as
a
state
list.
For
then
the
tip
message
format
gets
simpler
and
simpler.
So.
B
C
B
So
I'd
like
to
show
the
other
example
then,
unless
hanus
can
speak
because
you'll
see
there's
another
dimension,
that
makes
things
complicated
as
well.
So
here's
the
other
case.
Okay,
remember
this
case
was:
I
have
a
ua
that
depends
on
ta
that
a
that
depends
on
b,
okay
different
case
starting
from
the
ua.
In
this
case
I
have
an
untrusted
app,
that's
going
to
be
updated,
so
it's
already
installed
and
previously
dependency
on
ta1
right.
Sorry,
I'm!
B
This
one
now
depends
on
ta2
instead,
okay,
so
maybe
I
switched
out
a
crypto
library
and
I'm
now
using
a
a
different
ta
implementation
of
that
crypto
library
or
something
like
that.
Okay,
so
I
want
to
remove
the
dependency
on
the
old
ta
and
add
a
dependency
on
the
other
one.
Okay.
So
that's
what
happens
on
the
untrusted,
apps,
updater,
okay
and
now,
furthermore,
assume
that
space
is
scarce
such
that
I
only
have
space
to
install
ta2
after
ta1
is
removed.
Okay,
that's
the
example.
B
I
want
to
walk
you
through
okay,
that
if
I
tried
to
install
ta1
first
before
removing
ta2
I'd
get
sorry
out
of
space
okay,
so
what
happens
here
is
if
I
walk
through
the
flow
right.
The
query
response
gets
in
this
I'm
going
to
use
both
of
these
making
these
simple
to
say:
there's
only
one
tam
here
I
could
split
in
two
tams,
but
let's
combine
it
into
one
tam
just
to
keep
this
one
a
little
bit
simpler.
B
The
query
response
says:
hey,
I
need
ta1
and
my
and
I
no
longer
need
ta2
okay.
So
the
query
response
has
both
of
those
in
there
and
you
say
what
does
the
tam
do
now?
Okay,
it
says,
because
I
wanted
to
try
to
implement
this
and
I
scratched
my
head
for
a
while
saying.
How
do
I
implement
this?
What
do
I
do
in
the
tam?
B
Okay,
because
what
you
need
to
be
able
to
do
in
order
for
things
to
succeed,
you
need
to
first
send
a
delete
on
ta1
and
then,
when
that,
once
when
that
one
finishes,
then
you
can
install
ta2
right.
If
you
do
anything
else,
any
other
sequence,
it
won't
succeed.
Okay,
this
is
the
this
is
the
golden
path
right.
You
do
the
delete
when
the
success
comes.
You
do
the
install.
So
how
do
you
actually
do
that?
B
So
you
can
say
well.
What
I
want,
then,
is:
I
want
the
delete
success.
Response
could
trigger
the
install
message
going
to
what
is
the
trigger
is
the
install
because,
normally
so
far,
we've
only
talked
about
an
install
being
triggered
by
a
query
response.
Okay,
and
so
how
do
I
do
that?
Does
that
mean
that?
So
these
are
different
possibilities
right
says:
what
do
I
trigger
the
what
it
triggers
this
install
message
right,
because
the
query
response
that
I
needed
ta2,
but
I
only
sent
a
delete
message.
B
I
couldn't
send
the
install
then
I
had
to
wait
for
the
delete
to
finish
so
what
triggers
the
install
is
the
question?
Okay,
now
think
about
what
happens
if
the
okay,
so
what
happens?
If
the
success
message
is,
is
you
know
lost
for
some
reason
it
times
out,
because
there
was
some
connectivity
glitch
or
something
so
it
couldn't
contact
the
tam,
and
you
know
maybe
something
happens
with
another
thread
or
whatever
that
there
actually
is
another
query
response:
was
there
a
race
condition
or
what?
How
do
we
resolve
that?
B
What's
the
right
way
to
specify
the
10
behavior,
so
here's
four
options
there.
One
thing
we
could
do
is
to
make
the
problem
go
away
by
combining
install
and
delete
into
one
message,
and
so,
instead
of
having
to
serialize
these,
just
going
back
here.
Remember
back
here
in
option
one
we
can
pass
multiple
suit,
manifests
and
install.
So
this
is
this:
install
a
plus
b
is
the
same
as
two
separate
messages
and
for
the
delete
and
install
they're
two
separate
messages,
so
we
could
have
a
message
that
does
install
a
delete.
B
You
know
install
b,
delete
a
in
one
message
right.
So
that's
what
option
one
is
and
which
would
change
the
message
structure
to
combine
both
of
the
fields
in
the
install
and
delete
into
one
message
to
be
an
install
or
delete
message,
and
that
would
be
option
one
okay,
then
you
could
do
it
in
one
round
trip
and
not
have
to
wait
and
keep
state
and
remember:
oh
I'm
waiting
around
to
install
this
ta
two,
and
so
I
have
to
remember
that
he's
asked
for
ta2
and
so
on.
So
that
would
be
option.
B
One
option
two
is
to
say:
well
I
never
have
to
remember
anything.
I
only
triggered
the
install
of
the
delete
in
response
to
a
career
response
right
and
so
then
the
query
response
comes
in.
I
see
a
delete
and
an
install
request
and
sorry
I
ignore
the
install
I
sent
a
delete
next
time
around.
He
has
to
j,
he
has
to
connect
to
me.
I
generate
a
brand
new
query
request.
B
He
sends
a
career
response
saying
I
need
to
install
ta2
still,
and
you
say
great
now
I
can
install
ta2
okay
and
so
that
when
I
the
success
doesn't
trigger
anything.
I
have
to
cause
the
agent
to
generate
another
query
response
in
order
to
trigger
the
rest
of
the
flow
that
would
be
option.
Two
okay
option,
three
is
to
say
the
success
and
the
query
response
get
to
combined
into
one
message.
B
So
my
query
response
can
say,
and
I
now
need
ta2,
and
so
we
would
combine
the
fields
and
success
and
query
response
into
one
message
similar
to
option
number
one.
So
listen,
there's
still
two
round
trips,
so
the
analogy
here
is
delete
a
sorry.
Let's
say
here
delete
a
success
in
career
response.
Sorry,
it's
and
install
the
other
one
in
success.
Right
that
I
didn't
draw
the
picture
here.
B
But
this
has
a
bunch
of
extra
complexity,
because
the
success
is
giving
you
the
deltas
on
the
state,
like
I
just
finished,
installing
one
thing,
but
I'm
not
retelling
you
what
I
still
need
or
what
I
don't
need
and
the
query
response
is
the
full
state.
And
so
now
I
have
to
deal
with
being
able
to
parse
both
deltas
and
full
stage
and
deal
with
that
in
my
state
machine,
and
so
this
one,
in
my
opinion,
is
the
most
complex
out
of
these.
B
My
preference
would
be
option
number
one
only
because
to
brandon
or
whoever's
point
this
one
reduces
the
bandwidth
and
constrained
devices
by
getting
things
down
into
fewer
round
trips.
That's
option
number
one:
it's
the
only
one
that
has
the
that
has
not
an
extra
round
trip.
All
two
three
and
four
all
have
the
extra
round
trip
and
so
option
number
one
would
be
the
most
friendly
for
a
constrained
device
in
terms
of
bandwidth
and
latency.
G
B
B
Yeah
option
number
three
before
you
get
on,
I
was
explaining.
There's
no
continue
here,
there's
only
a
continue
in
option
number,
four,
the
continue
or
in
progress
or
something
option.
Number
three
has
no
new
messages
and
all
the
dependency
resolution
is
on
the
client,
meaning
the
agent,
and
this
is
the
one
that
is
my
preferred
approach.
The
disadvantage
on
this
one
is
that
the
10
sends
an
install
and
it
may
be
a
long
time
before
it
gets
the
success
message
for
a
because
the
dependency
resolution
has
to
happen
in
the
meantime.
G
But,
for
example,
here
in
this
exchange
you,
the
client,
in
with
the
install
the
client,
gets
the
da
and
then
suddenly
figures
out
that
oh,
it
needs
some
personalization
data
from
a
different
from
bambi,
let's
say,
and
but
it
has
no
way
to
send
that
message
to
time
b.
It
basically
has
to
wait
till
it
gets
by
magic.
What
is
there
or
is
that
the
message
that
is
not
it's
kind
of
hidden
here,
yeah.
C
C
B
Request
is
a
response,
and
so
what
happens
here
is
in
the
suit
manifest
of
a
it
identifies
the
dependency
which
in
this
case
it
depends
on
suit
manifest
b,
which
is
reachable
via
tam
b.
And
so
what
happens
is
he
has
to
open
the
zero
byte
post
off
the
tam
b,
saying
I
need
to
contact
you
ten
b
then
responds
to
the
tea
queer
request,
saying.
B
Okay,
so
this
was
saying
my
preference
is
for
option
number
three,
although
the
other
ones
could
work
with
effort,
okay,
but
option
number
three.
My
belief
is
that
this
is
the
simplest,
but
this
is
still
a
case
which
is
only
doing
install
and
stall.
So
the
other
variation
is
when
you
have
a
delete
and
install
whether
they're
two
different
tams
or
the
same
tam
and
in
the
case
with
the
same
tam.
B
B
That's
my
belief,
and
so
here,
because
I
was
trying
to
implement
this
during
the
hackathon.
I
was
working
on
the
delete,
behavior
right
and
I
came
into
this
case
here
in
my
implementation,
saying
I
don't
know
what
to
do
if
I,
if
I
get
both
of
them,
and
so
I
didn't
implement
the
case
of
what
happens
when
I
ask
for
both
of
them,
because
I
kind
of
stopped
here
and
said
file
issue
and
we'll
discuss
first
before
I
go
to
implementation.
B
And
so
because,
if
they
would
have
been
commanded
one
message
I
could
just
do
it
all
in
one
pass.
I
don't
have
to
keep
any
state
query
response
generate
stuff.
Send
the
install
slash
visit,
delete
flush,
all
state,
I'm
done
wait
for
the
next
time
that
he
connects
and
so
option
number
one
would
be
the
simplest
for
the
tam
yeah.
The
reason.
B
B
F
F
B
B
H
B
B
I
want
to
respond
to
nancy
that
I
didn't
understand
your
question.
Brandon
in
option
number
one.
This
combines
two
messages
that
are
going
from
the
tam
to
the
agent
option.
Number
three
combines
two
messages
from
the
agent
to
the
tam.
There
are
actually
two
independent
things
right
doing.
One
change.
B
D
B
B
A
A
A
C
A
E
B
B
So
here,
if
we
were
to
combine
them
and
I'm
going
to
compare
it
with
brendan's
suggestion-
which
I
hadn't
thought
about
before,
if
you
combine
them
into
one
message,
then
the
behavior
is
you:
do
all
the
deletes
before
the
installs?
Okay,
you
just
process
all
the
deletes
you
process,
all
the
installs,
then
you're
done
with
the
message,
and
you
send
back
your
your
your
error
or
success
with
the
suit
reports.
B
If
you
split
them
into
multiple
messages,
you
could
have
done
that,
like.
Let
me
go
back
to
say
this
message
here
with
install
a
comma
b.
If
you
took
brennan's
approach,
you
wouldn't
need
to
have
done
this.
You
could
have
done
another
variation
that
would
be
semantically.
The
same
would
be
install
a
and
install
b
as
two
different
t
messages
in
the
same
http
response
right.
That
would
be
equivalent
in
brendan's
example.
B
H
H
I
C
E
E
B
G
E
B
Okay,
any
other
thoughts
on
this,
because
otherwise
I'm
going
to
take
some
direction
and
and
do
pull
requests
for
people
to
review,
to
see
if
you
like
my
write-up
of
option,
one
on
this
slide
and
option
three
back
here,
because
I
think
that
gives
the
most
efficient
answers
in
terms
of
both
separate
compression
etc.
So
I
thought
brendan
you
made
me
think
to
see.
Is
there
actually
an
advantage
to
do
that?
Because
that's
that's
not
a
your
point
is
correct.
D
H
H
That
would
allow
for
all
of
these,
and
there
might
be
a
reason
why
you
don't
do
that,
and
one
of
the
reasons
might
be
the
the
the
latency
of
the
accumulated
batch
operation
here,
which
I
understand
now,
but
but
but
there
is
a
reason
why
you
haven't
done
this
and
you're
considering
merging,
install
and
delete
only
on
the
message
level
and
not
on
the
transfer
level,
and
that
is,
I
think,
an
option
that
has
to
be
at
least
spelled
out
at
some
point.
I
think.
B
B
I
think
it
was
one
way,
but
some
recent
iatf
team
meeting,
my
preference,
would
be
to
say
great
idea
what,
if
we
just
punt
that
to
say
at
such
point
in
time,
if
ever
as
we
take
your
dependency
on
taxi
board,
then
we
do
it
at
that
same
time
and
just
go
with
option
one
of
this
slot
as
being
the
simplest
one.
For
now
that
would
be
my
preference,
but
I
am
not.
I
don't
feel
strongly
about
it.
So.
D
B
I
guess
partly
my
preference
has
to
do
with
the
transport
spec
as
currently
is
currently
specified.
It
has
multiple
interoperable
implementations
right
now
and
number
one
does
not
require
any
changes
to
that
and
your
idea
would
require
changes
to
the
transport
spec
and
implementations
and
get
roughly
the
same
behavior
and
maybe
some
additional
advantages
that
you're
pointing
out.
But
I
don't
know
if
it's
if
the
advantages
are
worth
having
to
change
the
spec
and
the
implementations.
If
the
spec
has
already
completed
working
group
last
call
so,
but
it's
a
good
question.
D
B
F
In
the
future
discussion
of
the
tip
protocol,
we
really
need
to
this
defi
concrete
to
make
a
decision
who's
going
to.
Who
is
the
person
going
to
take
responsible
of
a
dependency
resolution,
so
the
agent
side
or
ten
side,
and
I
think
everything
today's
discussion
is
going
on.
The
agent's
side
is
going
to
take
care
of
the
dependency
and
then
after
yes,.
D
Manifest
the
way
the
suit
manifests
work,
the
only
entity,
that's
actually
trusted
to
do
dependency
resolution
is
the
manifest
processor
and
that's
just
because
anything
else
can
play
nasty
games
if
you
have
multiple
trust
domains
involved.
So
if
you,
if
you
have
to
evaluate
who
is
allowed
to
install
a
a
component
in
slot
in
positions
a
b
and
c,
then
you
need
to
make
that
determination
actually
on
device
there's
nowhere
else.
D
That
can
trust
it
to
do
that,
and-
and
so
the
result
of
that
is
that
dependency
resolution
can
only
be
done
on
device,
because
only
the
device
can
be
trusted
to
determine
whether
the
the
various
signers
of
the
various
components
actually
had
the
right
permissions
to
be
able
to
do
that.
So
that's
that's
the
effective
result
that,
when
it
comes
to
dependency
resolution,
the
the
manifest
processor
looks
at
what
dependencies
are
required
and
fetches
them,
as
required.
B
B
Message:
okay,
I
see
so
my
son
mentioned
so
I'd
ask
why
you
prefer
option
number
three
on
this
slide
instead
of
option
number
one
and
the
answer
was
each
remove
and
install
results
are
contained
into
a
single
report
which
is
better
and
I'm
asking
if
you
can
elaborate
on
in
what
sense
it's
better
right.
I
mentioned
why
I
think
number
one
is
better
in
the
metric
of
round
trips,
for
example,
but
in
what
metric
do
you
think
option?
B
Whatever
because
rtt,
I
don't
follow
because
option
number
one
has
a
one:
fewer
round
trip
option
number
three
has
two
round
trips
and
so
option.
Number
three
still
has
I'm
gonna
give
the
analogy
here
I
don't
know.
Maybe
I'll
use
this
one
gotta
say:
delete
success,
query,
response,
install
okay
and
so
there's
two
round
trips.
Where
option
number
one
combines
these
like
this
one,
and
so
it's
installer
delete
and
success.
So
the
equivalent
is
this
one
looks
more
like
option
one.
This
one
looks
more
like
option
number
three.
B
Error
message
or
success
message
can
include
more
than
one
suit
report
each
you
know
zero,
zero
or
more
suit
reports
right.
Each
suit
report,
reports
on
the
success
or
failure
of
a
particular
suit
manifest
by
digest,
and
so
your
response
can
report
on
any
number
of
successes
and
any
number
of
failures
in
the
same
success
or
error
response.
B
C
C
B
D
F
B
So
between
yesterday
and
today
I
tried
to
open
some
pull
requests
based
on
things
we
talked
about
yesterday.
Would
people
rather
spend
time
seeing
the
proposed
resolutions
that
we
kind
of
agreed
on
or
would
people
want
to
spend
time
picking
one
of
the
issues
that
we
haven't
discussed
yet
and
start
getting
into.
B
Or
what?
What
which
thing
to
talk
about
next
for
everybody
else
I'll
mention
the
nomenclature
that
we're
using
here,
ready
to
close
means,
it's
already
in
the
published
internet
draft
have
proposed
text,
means
that
sitting
in
a
pull
request.
That's
not
yet
merged
and
fixed
an
editor's
copy
means
it's
merged
and
get
in
the
github
copy,
the
editor's
copy,
but
not
in
the
submitted
drafts,
and
so
those
the
three
labels.
B
So
anything
that
says
fixed
an
editor's
copy
means
we've
already
merged
it.
It
was
on
that
list
of
stuff
that
akira
showed
in
the
group
yesterday
that
says,
some
things
have
been
merged
have
proposed
text
means
that
we
probably
already
talked
about
it,
but
there's
a
poor
request
with
text
that
you
may
not
have
seen,
and
blank
ones
are
ones
that
haven't
been
discussed
in
meetings
so
other
than
it
was
on,
probably
on
a
curious
slide
of
hackathon
issues,
which
is
why
I'm
asking
akira.
Is
there
something
you
think
you'd
like
to
talk
about?
B
Other
than
that,
because
I
can
pick
one
I'm
just
I
I
picked
the
previous
ones,
and
so
if
somebody
else
has
a
preference,
you
know
go
ahead
and
pick
one.
Otherwise,
I'm
happy
to
just
to
just
arbitrarily
pick
one.
But
I
look
at
the
other
implementers
to
see.
Is
there
something
else
that
you
consider
blocking.
B
B
B
B
B
There's
a
two
examples:
okay
is
embedded
directly
with
cbor
versus
embedding
it
as
a
beaster
that
you
didn't
have
to
call
another
seaboard
processor
on
okay
and
so
whoever
filed
this
says.
You
know
he
would
prefer
it
if
it
was
embedded
as
a
beaster,
but
you
don't
actually
see
the
manifest.
You
just
see
this
blob
here,
as
opposed
to
today,
where
you
paste
it
into
say
a
seaport
decoder
and
it
actually
decodes
inside
the
manifest.
D
As
in
we're
going
to
define
a
a
keyboard
tag
for
suit
envelopes,
I
important
step
here.
So
if
you
care
that
that's
there,
then
maybe
that's
something.
That's
other
than
that.
The
the
next
thing
you
should
probably
know
is
that
everything
inside
of
the
suit
envelope
is
already
b
string
wrapped,
so
that
may
or
may
not
affect
your
opinion
of
this.
D
B
D
What
it's
saying
is
that
it's
not
a
deep
structure
to
parse
the
manifest,
and
so
you
don't
lose
a
lot
by
parsing
it.
However,
that
being
said,
if
you
want
to
find
endpoints
safely,
then
you
probably
want
to
have
the
the
the
end
pointer,
something
that
you
can
actually
set.
What
that
will
also
point
out
is
that
you
get
a
little
bit
more
reusability
and
modularity
of
code,
if
you,
if
you
do,
structure
things
in
that
way.
D
One
of
the
arguments
that
I
was
given
for
wrapping
cozy
structures
in
b
strings
within
the
list
of
cozy
structures.
That
we've
got
was
that
this
was
what
the
cozy
libraries
actually
expected.
They
wanted
a
start
pointer
and
an
end
pointer,
and
if
you
didn't
have
an
end
pointer
that
was
difficult
to
do,
but.
G
D
And
that
that's
relevant
for
some
library
implementations
so
like
this
is
why
I
made
the
point
about
the
cozy
objects
within
within
suit
the
one
it
was
when
kuhn
was
looking
at
this.
He
said
that
it
was
really
hard
to
to
hand
a
cozy
object
to
a
cozy
library.
If
you
didn't
know
what
the
end
pointer
for
that
cozy
object
was
okay,.
B
H
B
So
I'm
going
to
go
on
83
we've
already
talked
about
the
meaning
that
was
part
of
the
slides.
81
was
part
of
the
slides.
We've
talked
about
this
one
came
up
on
the
hackathon
and
was
already
accepted,
and
so
I'm
going
to
skip
over
it.
It
mean
accepted
by
the
implementers,
and
so
it's
not
as
interesting
to
talk
about,
given
that
all
the
implementers
already
agreed
at
least
the
implementer
is
worth
a
hackathon
agreed.
I
should
say
basically
what
this
one
says
is.
F
So,
for
me,
it
wasn't
very
difficult
to
understand,
but
for
me
for
the
re
just
reading
the
draft,
the
text
and
the
the
person
who
never
attending
the
idf
discussion-
maybe
maybe
it
gets
confused,
there's
a
two
places
for
signing
and
who's
going
to
take
who's
going
to
be
responsible
for
the
signing,
keep
message
itself
and
the
suit
manifest,
and
my
my
take
my
understanding
is
the
suit
cheap
message
itself
is,
should
be
signed
by
tam
and
suit.
Many
faces
should
be
signed
by
tc,
just
ta
sign
or
t
developer
tc
site.
F
B
F
B
B
B
Other
integers,
like
data
item,
requested,
come
after
options,
and
then
you
notice
right
in
here,
there's
an
integer.
That's
not
up
there,
that's
before
options,
that's
the
contradiction,
the
spec,
that
the
teep
error
does
not
actually
conform
to
this
right
here
that
akira
discovered
during
the
hackathon.
So
so
we
said
well,
how
do
we
fix
that?
And
so
one
thing
we
could
do
is
say
this
is
correct,
in
which
case
all
we
do
is
we
move
the
error
code
down
and
notice.
This
is
a
uint
versus
this.
B
B
You
can
see
the
idea
was
to
change
it
to,
and
so,
if
token
is
optional,
which
we
kind
of
talked
about
yesterday
in
the
meeting,
then
if
token
is
there,
then
it
would
be
inside
the
options
portion
not
in
the
stuff
at
the
end,
because
it's
optional
so
there's
already
a
per
request
that
I
have.
That
actually
does
that,
although
some
of
the
token
question
is
still
open
based
on
the
suit
meeting,
all
right.
B
B
We
all
know
that
there
was
some
bugs
in
there
before,
but
you
can
see
the
star
in
the
label
right
here
and
then,
if
we
look
in,
I
think
it
is
the
you
know.
Maybe
it's
not
copied
into
here,
I'm
just
looking
to
see
if
the
query
request
is
actually
copied
into
this
issue,
because
it's
in
the
query
request
I'm
looking
for
here.
It
is
here
you
can
see.
There's
no
label
on
the
data
item
requested
here.
H
C
H
B
Yeah,
I
don't
have
it
up
here.
It's
that
yeah,
the
the
that
is
the
production
I've
lost.
The
issue
that
I
was
in
the
production
for
data
item
request
was
something
like
data
item
requested
equals.
You
know
uint
within
size,
four
or
something
like
that
or
size.
Eight,
something
like
that.
It's
defined
as
a
uint
with
a
maximum
size.
H
H
B
That
that
tells
me
so
thank
you
for
pointing
that
out.
I
think
there's
probably
some
cases
in
the
currently
submitted
internet
draft
that
define
numeric
values
for
some
things
that
are
on
the
left
side
inside
of
square
brace
things
that
can
probably
be
deleted
because
they're
never
conveyed
so
the
actual
numeric
value,
wouldn't
matter
so
there's
probably
a
couple
of
unused
productions
in
there.
We
can
delete.
H
H
G
B
B
H
J
B
H
B
H
B
H
No,
no
he's
not
right.
Let
me
explain
this
to
you.
If
you're
using
the
colon
notation,
that's
a
specialization
of
the
arrow
notation,
an
arrow
is
prefixed
by
a
type.
A
colon
is
prefixed
by
string,
it's
a
convenient
functions
for
people
that
come
from
json
because
they
expect
the
label
to
be
a
string
and
they
use
a
colon
there.
So,
if
you're
using
a
colon
for
a
label,
it's
always
a
string.
H
D
B
Right
because
I
was
the
one
that
inserted
this
type
here,
and
so
this
is
my
misunderstanding.
I
had
the
same
problem
that
brennan
you
just
mentioned
here
and
you're,
telling
me
that
my
intent
was
that
I
should
have
my
intent
may
be
wrong
right,
but
my
intent
was
that
this
should
be.
You
know
an
integer
followed
by
the
bister
and
I
should
have
used
an
arrow
if
I
actually
wanted
that.
H
H
B
C
H
Exactly
that
is
what
I
was
saying
and
for
human
comments.
I
personally,
as
a
style,
always
use
a
colon
notation,
because
it's
it's
it's
a
shorter
and
you
don't
have
to
define
the
type
for
never
being
used.
It's
just
useless.
So
in
arrays
I
typically
use
the
colon
notation
and
for
maps.
I
use
the
arrow
notation
gotcha.
Thank.
B
You
for
the
explanation
yeah
it's
explaining
yeah,
so
you
were
saying
down
here
in
this
there's
now,
I'm
back
in
the
issue
in
the
document
right
you're,
saying
add
the
human
comment
on
the
left
side
here
you
know
a
label
or
something
like
that
because
it
doesn't
affect
anything
anyway.
I
know
where
there's
nothing
that
affects
the
bytes.
It's
just
saying
it's
just
a
documentation,
clarity,
exactly
exactly
all
right!
Gosh!
I
learned
something
about
seaboard.
This
has
been
useful.
Okay,.
G
B
I
H
That
is
an
inherited
problem.
Cdl
meant
something
entirely
different
back
in
the
day,
but
we,
it
was
the
seaboard
definition
language
for
first,
and
it
was
something
else.
We
didn't
start
this.
We
just
put
it
over
when
it
was
abandoned.
It's
supposed
to
be
hbdl
there
you
go
hbdl,
yeah,
hey,
I'm
fine
with
cuddle.
B
All
right,
let's
pick
another
one,
a
couple
of
these
that
are
just
saying
yeah.
We
should
add
examples
into
the
spec.
So
this
this
is
one
of
the
two.
That's
just
saying.
We
should
use
examples
into
the
spec
this
one.
We
talked
about
in
slides
this
one.
We
talked
about
in
slides
this
one
we
talked
about
during
the
meeting.
B
That's
the
other
one.
That
says,
let's
add
an
example.
Once
we
have
an
example
of
a
suit
manifest
and
an
example
of
an
eat,
we
should
add
those
into
this
document.
It
says
here's
an
example
eat
that
would
be
usable
in
the
deep
context.
Here's
an
example
soup
manifest
would
be
usable
in
a
antique
context.
Just
so
we
have
examples.
B
That's
on
the
back
burner
until
the
soup
manifest
well
until
the
the
rat's
claims
for
eat.
Are
there
cause.
You
won't
see
the
example
until
there's
something
to
actually
put
in
there
the
soup
manifest
we
could
start
doing.
If
we
constructed
a
soup
manifest
for
say
you
know,
maybe
a
trust
zone
or
something
that
has
a
place
to
install
stuff
into.
We
could
do
that
now.
It
just
hasn't.
It
hasn't
blocked
implementers.
Yet
yep
those
are
already
in
the
latest
spec,
not
a
big.
B
G
Yeah
so
so,
when
I
was
working
on
implementation,
I
I
was
wondering
how
to
best-
and
this
is
on
using
utilize,
x1
509
certificates
in
this
whole
thing,
but
now,
since
we
pushed
a
lot
of
content
over
to
suit,
I
think
this
is
more
a
topic
for
suit,
because
that
the
reference
rfc
is
is
kind
of,
at
least
at
that
time.
I
need
to
reread
it's
like
kind
of
complicated,
but
I
think
this
is
now
more
a
suit
topic,
rather
than
deep.
J
B
B
G
B
I
alluded
to
it
in
one
of
the
slides
that
I
just
showed
in
the
the
long
discussion
we
had
for
45
minutes,
and
this
has
to
do
with
the
token
discussion
as
well,
and
so
it's
it's
there's
no
new
discussion,
this
one,
but
it
might
be
worth
just
me
pointing
out
what
what
40
is
tracking.
Okay,
maybe
I'll
do
that
just
by
referring
to
the
slide
here
where
I
covered
it.
B
It
was
here
remember
when
I
talked
about
this
line
here
that
says:
is
it
possible
to
send
something
unsolicited
if
you
don't
have
a
token
and
so
up
here?
The
question
is
remember:
if
you
have
a
zero
by
post
career
request
comes
down
and
you
send
a
query
response.
Okay,
so
the
question
in
option
in
40
is:
is
it
possible
to
send
a
query
response
without
having
to
have
the
extra
round
trip
to
get
the
query
request?
Okay,
because
this
was
possible
in
otrp?
B
B
B
B
B
Let's
go
back
to
51
since
since
we've
never
talked
about
this
one
before
and
only
I
think,
comments
there's
from
hanus
and
me
in
here.
So
currently,
if
we
look
in
the
teat
protocol,
spec
there's
the
error
code
space
right,
and
so,
if
you
hit
a
failure,
processing,
something
whether
it's
a
team
manifest
or
just
parsing
the
teat
message:
okay,
there's
an
error
code
space.
Now
in
recent
per
request,
we've
made
the
change
that
says
anything
that
would
belong
in
a
suit
report.
B
No
longer
has
a
teep
error
code
right,
there's,
just
a
t
bar
code
that
says
suit
manifest
processor,
failed
cc
report
see
the
suit
report
for
details,
but
those
things
that
are
t
failures
that
have
error
codes,
and
so
that's
what's
defined,
and
it
defines
this
I
currently
it
has
an
iana
consideration
section
that
says
we
propose
an
inter
registry
for
the
type
error
codes
and
the,
and
it
says
that
the
inner
registry
for
those
error
codes
is
listed
as
expert
review
right.
That's
the
spec
says
right
now.
B
B
If
you,
even
if
you
use
a
standard
error
code,
I
can
pass
a
custom
thing
in
the
text
string
along
with
it.
You
can
do
that
in
http.
You
can
do
that
in
the
teat
protocol
too,
so
you
can
already
already
extend
stuff
by
putting
stuff
in
the
text
string.
So
the
question
is:
what
policy
should
we
have
on
adding
new
error
codes?
Is
it
like
rfc
required,
in
which
case,
maybe
you
don't
need
an
iona
registry,
just
rev
the
rfc?
B
Is
it
expert
review?
Is
it
ietf
review
or
something
else?
Okay-
and
so
the
question
here
is,
it
would
be
simpler
if
we
didn't
have
to
have
ayanna
involved
or
if
we
did
then
maybe
iatf
review
instead
of
expert
review,
because
you
don't
need
a
designated
expert,
but
since
we've
never
actually
talked
about
this,
that's
why
this
issue
is
here
in
case
people
have
views
on
what
direction
we
should
take.
As
far
as
error
code,
extensibility.
B
Yeah,
I
don't
feel
strongly
about
this
one,
so
I'm
fine
going
along.
If
that's
what
everybody
thinks,
I
I'm
not
going
to
argue
against
it,
but
it
seemed
like
extra
complexity
without
the
rationale.
So
I
just
wanted
us
to
talk
through
what
the
rationale
is.
Do
you
think
that
people
will
actually
extend
the
error
code,
space.
C
C
B
B
B
If
you
have
code,
you
would
pay
attention
to
specific
error
codes
and
do
something
different
right
if
it's
just
for
human
logging
you're
going
to
use
the
text
string
for
that,
okay,
and
so,
if
somebody,
if
a
vendor
or
an
implementation-
or
you
know
a
future
standard-
wants
to
add
a
new
error
code,
the
question
is:
what
would
the
behavioral
change
be
if
it
saw
that
error
code?
If
the
tam
saw
that
error
code
coming
back?
What
would
the
tam
do
differently?
If
you
can
answer
that
question,
then
you
need
a
new
error
code.
B
B
When
I
filed
this,
I
couldn't
think
of
anything
that
the
team
would
do
differently
if
it's
an
error,
it's
an
error,
but
I
I
I
mean
there
might
be
a
couple
of
categories
of
errors
that
are
already
in
the
spec,
but
I
couldn't
think
of
new
categories.
So
that's
why
I
found
the
issue
is
to
ask
this
in
an
actual
meeting.
B
Yeah,
I
I'm
all
I
I'm
happy
to
have
at
iana
registry
an
expert
review
if
we
think
that
your
tam
is
going
to
have
a
case
statement.
You
know
a
switch
statement
with
new
cases
that
are
going
to
be
added
for
specific
values
and
it's
going
to
do
something
different
behaviorally.
But
I've
not
heard
that
argument.
Yet
that's
why
I'm
asking
so
I
don't
know
if
honest
you
have
any
examples
or
at
least
hypotheticals.
You
can
come
up
with.
G
B
Feel
free
to
think
about
it.
You
don't
have
to
answer
right
now,
but
I
won't
consider
this
one
closed
until
we
can
either
agree
on
what
the
answer
is
and
if
the
answer
is
yeah,
we
came
up
with
an
answer
and
then
it's
fine
as
the
as
the
document
has
it.
But
if
we
can't
come
up
with
an
answer,
then
asking
iona
that
doesn't
have
a
designated
expert
and
having
anna
review
the
stuff.
It's
just
more
overhead
that
I
don't
know
if
it's
actually
necessary.
So
all
right!
B
I'm
gonna
look
for
anything
else,
because
otherwise
I
think
that
the
other
one's
just
examples
requests
for
examples.
Anything
else
here,
nope
those
are
both
ready
to
close.
So
I
think
we're
at
the
bottom.
So
everything
else
is
just
open.
Pull
requests
ready
to
be
reviewed.
I
guess
by
the
without
going
through
these
just
to
get
a
repeat
question
to
I
think
nancy.
Do
you
have
eggman
on
this
repo.
B
I
don't
know
if
nancy
can
hear
me
right
now
whenever
I
file
one
of
these
issues
whenever
I
follow
open
a
pull
request
here.
I
add
all
of
this
t
protocol
spec
authors
other
than
myself,
except
for
I
can't
add
accurate,
because
I
have
to
keep
doing
you
know
akira,
please
review
and
comment
because
the
it's
he's
not
showing
up
as
a
contributor,
so
I
need
one
of
the
admins
to
fix
that
so
all
right.
Well,
I
propose
that
we
end
here.
B
B
J
B
So
if
you
don't
mind
closing
the
issues,
then
we'll
just
mark
them
ready
to
close.
If
you
want
to
keep
doing
that
for
the
protocol
spec,
that's
fine,
I'm
happy
to
do
whichever
process
that
you
want
so
sure.
Okay,
all
right
great!
That's
everything
that
I
think
is
useful
to
go
through
on
this
call
here.
So
unless
nancy
has
anything
else,
I'm
gonna
stop
sharing.