►
From YouTube: IETF106-SUIT-20191119-1330
Description
SUIT meeting session at IETF106
2019/11/19 1330
https://datatracker.ietf.org/meeting/106/proceedings/
B
A
C
C
C
We
yeah
we've
done
at
least
one
working
group,
less
call
so
I
think
we're
gonna
want
to
have
some
discussion
during
the
draft
updates
about
next
step
on
on
those
two
documents.
We
also
have
the
suit
manifest,
which
is
progressing.
You
know
rather
well.
There's
been
some
recent
updates
to
that
and,
and
so
I
know,
I'm
personally
interested
in
where
the
next
steps
are
there,
two
milestones
we're
doing.
Okay
on
our
milestones,
we
recently
revised
them
we're
expecting
to
submit
three
documents
to
the
IAS
G.
There
are
two
documents
to
do
is
G
this
month.
D
Ok,
this
hackathon
announcement,
as
you
can
see
if
you
have
been
following
the
mailing
list
and
you've
seen
that
we
boasted
a
few
males
before
doodle
boil
finding
a
date
for
a
hackathon
and
be
decided
not
to
do
it
in
at
this
meeting,
but
actually
do
it
separately.
So
this
it's
always
a
question
of
distraction
and
so
on.
D
This
is
a
very
busy
meeting,
as
you
know,
or
all
IETF
meetings,
a
very
PC
and
we've
been
quite
successful
in
doing
the
hackathon
last
I
mean
in
actually
in
Berlin,
so
we
thought
that
we
should
do
that
again
with
the
help
of
Matias
I,
don't
see
him
in
the
room
right
now,
or
is
he
okay?
But
in
any
case
he
set
up
a
website
which
I
think
by
now
includes
a
registration
link.
D
So
the
idea
is
that
we
have
a
three
day
event:
three
four
days,
the
first
day
with
a
tutorial
and
that
tutorial
is
focused
on
giving
you
some
or
enough
information
hands-on
information.
So
you
can
then
actually
be
productive
at
the
hackathon.
So
this
is
not
a
one
day
slideshow,
but
it's
a
the
whole
thing.
D
Yet
the
hardware
selection,
but
for
the
rats
group
we
are
thinking
about
using
one
of
the
latest
nxb
our
bots
on
supporting
arm
be
a
dem.
So
we
can
actually
test
out
these.
The
results
from
from
the
rats
at
the
station
work
for
deep
emmanuel
suggested
a
port
also
from
nxp
one
that
is
an
earlier
generation
using
Bluetooth
Low
Energy,
using
v7m
and
for
the
software
updates
in
not
for
that
for
the
deep
work
they
might
be
or
Dave
suggested
that
we
actually
use
virtual
machines.
D
But
in
addition,
I
want
to
also
order
either
the
port
that
he's
recommended
on
the
list.
Today,
if
you
have
been
to
the
earlier
deep
meeting
or
the
ste
stm32
mp1
port,
that
I've
been
using
recently
recently,
so
there
would
be
a
mixture
of
different
devices
out
there
and
and
depending
on
who
registers
for
what
will
make
those
ports
available.
D
There
will
be
a
little
bit
of
effort
for
you
for
those
who
participate
up
front,
because
we
need
to
make
sure
that
we
have
the
software
development
set
up
appropriately
sort
of
we
don't
waste
time.
D
D
Okay,
that's
a
short
presentation
short
because
we
have
been
running
the
working
group
last
call
since
I
think
February
or
April.
So
it's
a
little
longer
working
group
last
called
and
usual,
but
I
have
been
a
couple
of
updates
in
between
based
on
the
feedback
in,
and
this
is
just
a
sort
of
a
brief
history
or
status
version.
D
Five
four
included
some
extra
text
on
boot
loaders
because
there
was
the
request
and
in
version
six,
we
added
the
deep
related
information
because
of
the
decision
from
the
working
group
to
harmonize
the
work
between
those
two
groups.
So
that
has
been
done
any
more
recently.
Kathleen
has
posted
a
review,
a
more
detailed
review
and
which
led
to
version
seven,
which
is
the
most
recent
version
you
have
under
on
in
the
repository
that
been
various
changes
throughout
the
document.
D
So
that's
why
I
made
this
a
little
bit
more
explicit,
and
also
we
talked
about
sort
of
term
meant
under
mandatory
to
implement
security,
algorithms
and
I
try
to
be
a
little
bit
more
generic
here,
brought
it
in
listing
his
specific
algorithms,
because
probably
the
architecture
isn't
the
right
place
to
make
those
recommendations
anyway,
which
is
in
line
with
what
we
did
also
two
hours
ago
or
so
in
deep
in
the
deep
architecture.
So.
D
But
maybe
the
wording
could
be
better
but
has
to
be
defined
elsewhere,
not
in
this
document.
A
D
E
C
C
A
F
D
D
Okay,
good
idea!
So
the
other
question,
which
I
think
was
a
little
bit
more
generic,
which
I
wasn't
able
to
answer
in
form
of
text
in
the
in
the
document
yet
or
at
all,
is
the
document
currently
from
the
history
of
the
group
focused
very
much
on
low-end
IOT
devices
and
Kathleen
was
saying
like?
D
So
we
don't
need
to
work
on
that,
but
one
could
imagine
higher
end
IOT
devices
that
use
classical
Linux
maybe
use
some
of
the
stuff
we've
work
on
in
in
the
deep
working
group,
and
so
you
may
actually
use
that
the
same
software
update
mechanism
there
that
we
develop
here
and
is
there
anything
in
the
document
that
we
should
be
doing
to
explicitly
call
out
those
cases
as
well
and
yeah,
I
I?
And
it's
a
it's
really
a
question
for
a
working
group
to
rather
than
me
unilaterally,
suddenly
expanding
the
scope
of
the
work
here.
A
So
I
think
maybe
question
for
Brennan,
because
I
thought
that
there
was
a
statement
that
he
had
already
added.
But
maybe
it's
a
super
manifest
document.
There
was
some
statement
about.
You
know
nothing
in
this
prevents
its
use
in
larger
scenarios,
some
paraphrasing
of
that
but
I,
don't
remember
which
document
they
got
put
into
you,
but
that
came
up.
D
Maybe
we
missed
something
because
so
far
the
focus
was
on
something
else
and
even
a
deep
case,
while
the
devices
may
be
or
are
larger
and
different
to
what
is
the
primary
focus
here
so
far
there
we
have
been
talking
about
updating
trusted
applications
and
what
Kathleen
was
talking
about
is
updating
everything
else
as
well,
including
the
rich
operating
system
like
in
Linux,
updating
the
Linux
I'm,
fitting
the
the
monitor
code,
updating
the
the
REE
OS
and
so
on.
It's
on.
E
Brendan
go
ahead:
oh
yeah,
the
the
update
that
I
put
in
was
definitely
in
the
manifest
document,
and
it
said
essentially
that,
while
it's
for
informed
by
firmware
update,
use
cases,
there's
nothing
that
prevents
using
it
anywhere
else
and
in
fact,
I.
Don't
know
how
useful
this
is.
But
I
have
seen
a
few
a
few
instances
of
people
using
an
update
system
very
similar
to
this,
for
updating
Linux
devices
and
even
seen
some
discussion
about
using
it
to
update
Windows
devices
with
whole
system
images.
A
G
D
F
G
G
Maybe
the
issue
is
that
that,
as
the
document
goes,
Kathleen's
issue
is
the
document
goes
to
other
parts
of
her
and
other
companies
they're
like
oh,
but
this
is
only
for
IOT
right,
blah,
blah
blah
blah
or
whatever
that
means,
and-
and
so
we
actually
just
have
to
kind
of
beat
them
over
the
head.
Is
that
really
what
it
is
because
I'm
like
well
I,
totally
expect
to
someone
to
upgrate
upgrade
the
BMC
of
any
kind
of
a
server
system
using
suit
right?
G
The
the
basic
micro
controller,
okay,
I
totally
expect
that
that's
that's
I
I,
think
that's
totally
in
in
skiing,
in
scope,
but
but
maybe
the
guys
over
there
thinking.
You
know
that
bill
3u
servers
just
hasn't
occurred
to
them
that
they're
BMC's
an
IOT
device.
Does
it
turn
power
on
and
off,
yeah
right?
Well,.
D
G
Maybe
we
just
need
more
examples.
That's
that's
all
this
is
explicitly
included,
for
instance,
blah
blah
blah,
and
we
should
just
ask
for
you
know:
10
10
10
points
of
weird
things
that
people
thought
about
that
would
be
appropriate
for
suit.
That
no
one
wouldn't
know
wise
think
about
I
mean
what
why.
C
A
C
E
E
Last
call
has
been
going
on
for
a
while,
but
I
think
that
maybe
the
middle
of
August
do
not
many
people
notice
that
it
had
it
has
started.
We've
had
a
fair
bit
of
review
already.
I
actually
just
got
a
review
yesterday,
which
I'll
come
to
in
a
little
bit.
So
I
think
that
we
are
progressing
pretty
well
here.
E
If
anyone
has
any
further
comments,
now's
the
time
next
slide,
please
so
one
of
the
big
changes
was
that
I've
added
in
a
few
new
threats
and
security
requirements
that
justify
the
architectures
mention
of
an
end-to-end
security
model.
Previously
that
hadn't
actually
been
mentioned
in
the
information
model
next
slide,
please.
So
there
are
a
few
different
threats
that
I
added
in
to
to
cover
that.
So
first
there
was
the
interception
of
data
between
the
update
service
and
the
device,
and
then
he
exposure
threats,
a
specifically
extraction
of
signing
keys
from
some
form
of
signing
service.
E
That
would
be
if
it
were
hosted
or
potentially,
if
it
is,
is
a
non
hosted
service,
then
as
well.
The
possibility
of
a
manifest
being
modified
in
some
way
between
the
author
attempting
to
create
a
manifest
and
it
actually
arriving
and
being
signed
by
whatever
signing
service,
be
that
local
or
remote.
E
E
E
The
intent
there
had
been
that
you
didn't
need
additional
authentication
steps
to
be
able
to
just
replace
the
URI
of
a
manifest,
so
that
a
gateway
for
example,
would
be
able
to
override
where
a
device
would
look
for
its
update
or
look
for
a
further
manifest.
But
what
was
pointed
out
to
me
was
that
this
would
allow
a
an
attacker
that
is
able
to
compromise
the
channel
or
the
communication
partner
to
then
get
all
of
the
devices
that
it
communicates
with
to
make
arbitrary
requests
over
the
network.
E
So
this
seems
like
we
should
probably
plug
that
hole
and
so
I've
explicitly
disallowed
that
in
the
in
the
information
model,
now
and
I'd
be
very
interested
in
the
feedback
from
the
working
group
on
that
particular
change.
One
other
minor
change
in
the
information
model,
as
a
result
of
the
reviews
that
I've
just
recently
received,
was
to
define
a
maximum
size
for
the
integrated
payload.
Now
the
maximum
size
that
I've
defined
is
the
whole
thing
has
to
fit
in
memory,
which
I
think
is
a
pretty
reasonable
approach
to
saying
how
big
it
can
be.
E
Now
we
might
need
to
be
more
specific
than
that
and
again
I'd
be
interested
in
the
working
groups,
feedback
on
whether
we
should
be
defining
a
numeric
maximum
size
or
leaving
it
as
just
the
whole
thing
has
to
fit
in
RAM
next
slide.
Please
so
we've
asked
for
further
reviews
and
we
want
to
make
sure
that
the
document
is
complete
and
I
think
that
it's
in
quite
good
shape
now
and
so
I'd
like
to
know,
if
there's
any
more
feedback
next,
please
or
is
that
it
I
think
that's
the
last
one
is
nice.
A
I
Okay,
yeah
just
bouncing
back
on
a
comment
from
Brendan
on
whether
we
have
to
put
in
numerical
limits
to
the
size
of
payloads,
and
things
like
that.
I
think
this
might
be
a
little
bit
difficult
like
on
our
and,
for
example,
with
our
riot
implementation.
We
really
try
to
push
down
the
RAM
requirements
quite
a
bit
such
that
payload
actually
definitely
does
not
fit
in
RAM.
So
we
use
things
like
clock
wise
and
things
I
had
to
actually
bring
down
the
minimum
Ram
requirements.
I
So
I
think
we
have
to
be
careful
here
not
to
not
to
put
any
strain
on
on
the
RAM
requirements.
We
may,
however,
try
to
look
at
flash
requirements.
I
mean
if
you
can't
like
put
there
somewhere
so
we're
in
the
memory
and
maybe
not
in
the
RAM
that
this
whole
payload.
Then
you
have
a
problem
but
also
yeah.
That
was
it.
E
Hi
I'm,
Manuel,
sorry,
I,
I,
think
I
must
have
not
been
quite
clear
enough.
This.
This
is
specifically
for
the
integrated
payloads.
So
this
would
be
if
you're
passing
something
very
small
along
like
I,
don't
know,
maybe
an
encrypted
key,
that's
being
delivered
to
a
device,
so
not
the
whole
payload
of
the
of
a
firmware
update,
but
instead
just
a
small
payload
that
a
device
is
using
for
some
other
purpose
and.
A
Clarifying
question
Brendan:
please
thank
you,
since
we
just
had
the
discussion
about
whether
this
could
scale
up
to
larger
class
devices
than
class
to
you.
Are
you
thinking
that
the
maximum
size
would
be
independent
of
device
size?
Are
you
thinking
that
the
maximum
size
would
be
for
the
class
2
devices
or
something
else
well,.
E
A
Ok,
sorry,
let
me
rephrase
the
question
if
it
has
to
fit
in
the
devices
memory
who's
expected
to
know
how
big
the
devices
memory
is
and
what
that
limit
is,
because
is
the
manifest
author
expected
to
know
that,
because
maybe
the
device
is
a
tiny
IOT
device?
Maybe
it's
an
8
gig
memory
device
is
the
manifest
author
expected
to
know
that,
or
is
the
spec
take
some
number
or
what?
What
is
your
proposal?
Yeah.
E
That's
exactly
the
problem
that
and
that's
why
I'm
asking
for
feedback,
so
my
inclination
would
be
to
say
all
right
one
of
two
things:
either
the
maximum
size
should
be
defined,
as
you
know
enough
to
fit
a
a
key,
IR
aqui
wrapped
key
or
it
should
be
defined
as
it's
up
to
the
implementer
to
know
exactly
what
fits
I.
Don't
really
like
it's
up
to
the
implementer
to
know
what
fits,
but
at
the
same
time,
picking
a
number
out
of
the
air
might
break
some
use
cases.
A
E
C
C
E
Memory
right,
okay,
so
the
the
other
possibility
here
is
that
we
look
at
capability
reporting.
We've
talked
about
capability
reporting
a
bit
in
the
manifest
Draft,
and
maybe
that's
something
that
we
need
to
address
as
a
working
group.
So
capability
reports
would
possibly
handle
this
situation
where
you're
able
to
get
information
back
from
the
device
at
the
time
of
manifest
creation
and
look
at
you
know
how
big
of
a
manifest
will
this
device
accept,
and
then
that
makes
it
sort
of
academic.
D
D
A
So
this
is
a
favor
it's
occurring.
There
is
a
slight
analogy
with
something
like
a
reassembly
buffer
in
protocols
where,
for
example,
what
ipv6
did
is
they
said
you
must
be
capable
of
reassembling
something
of
at
least
this
size
for
some
number,
like
1280,
bytes
or
pick
a
number
or
whatever,
but
you
were
allowed
to
pick
something
larger
than
that,
and
so
that
means,
if
you
are
authoring
something
if
you
want
to
be
perfectly
interoperable,
you
make
sure
it's
no
larger
than
that
minimum.
A
If
you
have
specific
knowledge
of
the
other
end,
you
could
go
larger
than
that
and
still
be
compliant.
So
that
would
be
a
possible
approach
that
we
could
take.
I,
don't
know
if
that's
the
right
thing
or
not,
but
that
would
be
a
way
that
actually
supports
both
sides
and
says
you:
it's
not
a
maximum
size,
but
it's
the
maximum
size
at
which
interoperability
is
guaranteed
without
without
knowledge
of
the
other
ends.
Okay,
that's.
F
A
J
C
E
C
Right
so
I
mean
thinking
through
that.
So
if,
if
you
post
something
to
the
list
in
a
couple
of
days,
maybe
we
we
post
an
updated
draft
next
week,
if
we
after
we've
had
some,
you
know
some
conversation
about
the
the
solution
and
then
we
could
have
a
couple
weeks
of
of
last
call
review
before
we.
You
know
we
close
out
the
document
that
would
put
us
a
week
into
a
week
into
December,
but
that's
not
too
bad,
but
would
something
like
that
be
doable.
C
K
E
So
I
was
looking
here
at
defining
the
maximum
size
of
an
integrated
payload,
rather
than
the
maximum
silence
of
the
manifest
itself.
It
might
be
more
useful
to
define
a
maximum
size
of
a
manifest,
but
that
can
be
highly
dependent
on
the
on
the
use
case.
It's
not
a
fixed
size
format
and
in
that
respect
I
mean.
Maybe
that's
one
of
the
things
that
I
need
to
work
through
in
the
next
couple
of
days.
E
What
makes
sense
for
the
maximum
sizes
in
in
that
respect,
when
we
look
at
things
like
embedding
into
boot,
loaders
keeping
it
really
small,
is
very
important.
So
getting
the
size
of
the
manifest
down
for
that
use
case
is
something
that
we
we
should
perhaps
be.
You
know,
defining
the
new
maximum
size
for
the
manifest
in
in
each
use
case,
I
mean
if
you
look
through
the
examples
that
are
in
the
manifest
document
already
then
there's
a
few
examples
of
what
sizes
could
be
I.
K
E
I
mean
the
other.
The
other
thing
that
might
show
up
there
is
configuration,
so
you
could
imagine
fairly
easily
a
bit
of
sea
bore
being
delivered
in
an
integrated
payload,
because
it
makes
more
sense
to
do
that
than
to
have
a
completely
separate
transfer
to
handle
that
you
know
relatively
small
chunk
of
data
and
and
that's
where
things
get
a
little
bit
more
complicated
because
what's
a
what's
the
same
size
of
seaboard
to
deliver
to
a
device
in
in
the
manifest
rather
than
outside,
of
the
manifest.
E
So
that
so
that's
essentially
the
use
case
that
I
am
trying
to
work
through
is,
if
I'm
delivering
something
reasonably
arbitrary,
like
a
configuration
blob
in
the
manifest.
How
big
should
that
be?
Well,
that's
highly
dependent
on
exactly
what's
being
delivered,
and
that's
why
I
I'm
sort
of
trying
to
work
through
this
before
making
a
direct
recommendation,
as
I
said,
this
is
something
that
only
came
up
in
the
last
24
hours
for
me,
so
I
haven't
really
had
time
to
work
through
it.
Yet
so.
K
After
listening
to
this
I
think
I've
changed
my
mind.
Maybe
we
can
document
all
these
considerations
and
not
give
any
minimum
or
maximum
I
think
for
implementers,
like
even
if
they're
pushing
updates,
they
probably
do
some
kind
of
testing
before
they
start.
You
know
push
any
any
sensible
developer
would
do
some
kind
of
testing
before
they
start
pushing
updates.
So
we
document
all
this
and
then
don't
give
any
likes
min
or
max
thanks.
A
E
No,
there
isn't
at
the
moment
what
it
says
right
now
is
that
it
has
to
fit
in
Ram,
okay
and
the
reasoning
for
it
has
to
fit
in
RAM,
which
isn't
in
github
I
should
probably
put
that
in
is
that
we
we
need
to
be
able
to
verify
the
signature
across
the
manifest
in
one
go,
because
otherwise
that
leads
to
a
time
of
check.
Time
of
use,
vulnerability.
E
A
So,
in
the
interests
of
facilitating
consensus,
since
we
had
one
person
actually
express
an
opinion
rather
than
saying
need
to
think
about
it,
then
is
there
anybody
that
would
have
an
objection
that
should
they
should
we
actually
choose
to
go
with
the
not
defining
a
strict
number
in
here
is
there.
Anybody
would
actually
object
to
that
trying
to
facilitate
some
advice
for
consensus.
I
one
person
said
that
makes
sense.
A
E
C
C
E
Right
next
slide,
so
I
we
had
a
draft
five
approved
for
adoption
about
four
months
ago
now
we
incorrectly
said
submitted
version
four,
sorry
about
that,
so
that
was
immediately
updated
to
or
not
immediately
shortly
after
updated
to
version,
one
which
was
the
correct
version
version
2
was
announced
on
the
list
recently
and
contains
some
relatively
minor
changes,
mostly
in
terms
of
text.
Not
encoding
next
slide,
please.
E
So
primarily
what
was
added
was
an
interpreter,
behavior
section
which
defined
an
abstract
machine.
Now
that
is
mostly
informational.
It's
essentially
a
mechanism
to
help
implementers
to
understand
how
to
construct
the
interpreter.
The
other
thing
that
this
will
do
is
make
it
a
little
bit
easier
for
us
to
do
some
testing,
so
we
also
added
templates
for
constructing
manifests
and
then
the
text
field
items
which
have
been
missing
for
a
while
next
slide,
please
so
for
interpreter
behavior.
It
goes
through
a
number
of
steps.
First,
there's
a
set
up
phase.
E
So
that's
what
to
do
before
invoking
the
interpreter.
It
includes
things
like
clearing
out
any
parameters
or
making
sure
that
you're
loading
the
most
recent
valid
manifest.
The
next
thing
is
required.
Checks
and
that's
things
that
the
interpreter
has
to
do
so,
for
example,
that
would
include
validating
signatures
that
would
include
making
sure
that
there
is
a
vendor,
ID
and
class.
Id
check
that's
been
done,
then
there
are
commands
that
have
to
appear
in
the
manifest
and,
as
I
said,
that
could
include
the
vendor
ID
and
class
ID.
E
Then
it
goes
through
to
explain
how
an
interpreter
should
behave,
and
the
intent
here
is
that
two
different
interpreters
should
interpret
each
manifest
in
the
same
way,
and
that
gives
us
the
basis
for
enabling
consistent
behavior
across
devices
and
across
implementations,
which
will
be
really
important
for
interoperability
later
on,
and
then
we
define
an
interpreter
abstract
machine.
Now.
This
is
a
relatively
lightweight
definition.
E
It's
just
a
series
of
statements
of
exactly
what
each
different
element
in
the
manifest
commands
should
do,
and
the
idea
here
is
that
we
should
be
able
to
build
very
fine-grained
test
vectors
for
interpreters
and
interpreter
validation.
Suites
so
that'll
make
it,
hopefully
a
lot
easier
for
people
to
be
confident
that
their
manifest
interpreter
is
behaving
according
to
the
spec.
E
Next,
please
I've
also
gone
through
and
added
some
sections
defining
what
serialized
processing
would
do
as
an
interpreter.
So
that's
where
each
component
ID
is
processed
in
sequence
and
that's
out
of
sequence,
with
the
with
the
normal,
manifest
flow.
The
the
idea
here
is
that
for
extremely
Ramkin
strange
devices,
it's
still
possible
to
handle
multiple
components
and
then
for
large
devices,
where
parallel
processing
is
relevant.
E
So
then
I've
added
a
new
section
on
creating
manifests,
and
this
includes
one
mention
of
including
source
material
in
the
text
section
of
the
manifest
now.
This
might
be
interesting
for
intermediate
systems.
Since
the
author
can
provide
a
a
document
that
is
in
a
more
conventional
form
and
that
would
allow
intermediate
systems
to
handle
it
simply,
but
then
at
the
same
time,
that
can
be
pruned
with
the
with
the
severable
section
that
it
like
meet
with
a
text
separable
selection,
so
that
that's
never
actually
delivered
to
the
end
node.
E
So
we've
also
added
templates.
So
the
idea
there
is
that
it
gives
the
authors
of
tooling
some
help
on
exactly
what
different
use
cases
should
look
like
once
they
are
built
into
a
manifest
and
then
there's
a
few
use
case
templates
that
explain
exactly
which
commands
you
would
need
to
accomplish
different
tasks
next
slide,
please
so
I've
added
in
some
text
field
definitions.
Those
have
been
noted,
noticeably
missing
from
previous
versions
of
the
draft.
So
there's
a
few
there's
the
the
ones
you
would
expect
here.
E
Next,
please
so
for
next
steps.
We
think
that
the
draft
is
in
a
pretty
good
state,
there's
been
a
few
editorial
PRS,
which
most
of
which
have
been
merged,
we're
wondering,
if
there's
a
better
name
that
we
could
come
up
with
than
just
suit
manifest,
because
right
now,
if
you
don't
know
what
you're
looking
for
I
had,
you
probably
won't
find
it
for
technical
proposals
for
Version
three.
E
E
So
the
thing
about
run
sequence
was
we
originally
introduced
it
to
allow
conditional
processing,
but
it
was
a
bit
ambiguous
on.
What's
whether
it
was
a
soft
fail
or
hard
fail,
and
then
it
didn't
have
an
else
clause
which
meant
that
if
you
went
through
and
tested
a
number
of
sequences
and
they
all
failed,
there
was
no
way
to
catch
that
case
in
the
manifest
itself.
So,
as
a
result
of
that,
we
introduced.
E
We
introduced
the
try
each
construct
now
the
thing
about
that
was
that
it's
explicit
that
it's
soft
failure,
even
in
its
name-
and
it
definitely
has
an
else
clause.
So
the
question
is:
should
we
deprecate
run
sequence
now,
there's
the
possibility
that
we
could
use
run
sequence
for
another
use
case,
which
is
specifically
serialized
out
of
order
processing.
The
idea
there
is
that
you
have
several
sequences,
each
of
which
need
to
be
executed
in
order
internally,
but
the
order
that
you
process
the
sequences
in
doesn't
matter.
E
E
We
could
prune
some
information
because
maybe
it
they're
a
bit
too
verbose
right
now,
for
example,
there
was
a
JSON
representation
in
each
of
the
examples
and
I'm
not
sure
that
we
actually
need
the
JSON
representation,
since
we
also
have
the
Seaboard
decode,
our
sorry
seaboard,
debug
info
version
of
the
information
we
can
move
them
to
an
appendix.
In
fact,
we
should
move
them
to
append
an
appendix
if
we
do
nothing
else
and
the
other
option
would
be
to
move
them
to
another
document
with
more
extensive
use
case
information
now.
E
E
So
what
I'm
going
to
propose
is
a
map
test,
execute
structure
now.
The
idea
here
is
that
you
first
have
a
list
of
component
ID
parameter
set
pairs,
so
a
set
of
parameters
that
gets
applied
to
a
particular
component.
Id
then,
after
that,
you
have
a
test
that
makes
sure
that
that
set
of
parameters
or
the
each
set
of
parameters
is
valid
and
aborts.
If
it's
not
and
then
an
execute
which
runs
a
command
sequence,
that
can't
soft,
fail
and
wearing
an
error
would
cause
command
termination.
E
Next,
please
so
there's
an
encoding
there
and
I
should
stress
that
the
idea
here
is
that
there
is
exactly
one
test
sequence
and
exactly
one
execute
sequence:
it's
not
one
test
sequence
per
parameter
list
next
slide,
please!
So
there's
a
trade-off
here.
So
to
make
this
work
properly,
there
has
to
be
a
temporary
set
of
parameters
that
is
used
before
a
test
happens
to
prevent
side
effects
in
the
system,
so
that
that
does
cost
some
RAM
to
implement.
The
the
benefit,
though,
is
that
it
does
produce
a
smaller
encoding
of
repeated
patterns.
E
E
E
Now
you
you
would
anticipate
that
the
parameter
set
will
not
be
applied
to
your
overall
system
state
until
after
the
test
has
succeeded,
but
because
of
the
simplicity
of
the
interpreter,
you
would
have
to
apply
the
parameter
set
before
running
the
test
in
order
for
that
test
sequence
to
to
have
any
effect,
since
it's
going
to
work
on
the
parameters
that
you've
just
set.
So
the
temporaries
are
there
to
manage
the
state
of
the
of
those
parameter
sets
until
after
the
test
has
succeeded,
at
which
point
the
temporaries
would
become
committed.
E
Now
my
recommendation
is
that
if
we
use
it
at
all,
it
should
be
required
under
these
specific
circumstances,
if
you
have
more
than
one
component,
it
should
be
required,
and
if
you
have,
if
you're,
using
something
like
a
V
offset
or
a
B
offset
based,
execute
in
place
images,
then
it
should
be
required
under
other
circumstances,
for
so
for
single
image
devices
with
a
single
offset,
then
it
would
not
be
required
at
all.
So
that's
my
recommendation.
C
C
E
E
Okay,
well,
in
the
absence
of
any
commentary
on
that,
let's
move
on,
so
the
other
option
would
be
for
each
component.
It's
a
bit
easier
to
understand,
but
it's
much
less
flexible
than
the
map
test
execute
construct
and
it
implements
only
the
for
each
component
in
a
list.
Do
something
structure
rather
than
all
four
of
those
examples
that
I
provided
earlier,
and
it
expands
on
the
the
previous
concept
of
using
true
as
a
catch-all.
E
This
kind
of
construct,
but
the
for
each
component.
One
certainly
is
a
bit
simpler
and
I.
Think
that's
the
last
one.
Oh
no,
it
isn't
there's
a
road
map.
Okay!
Yes,
so
we
have
a
fairly
stable
document
already,
but
we
want
to
make
sure
that
it
is
just
ready
to
go
before
the
hackathon
in
February
and
we're
planning
to
have
code
and
tools
developed
as
input
for
that
event.
E
H
Have
one
comment
on
getting
things
smaller,
I'm
somehow
involved
in
creating
a
lot
of
SIBO
data
items
in
the
last
year's,
and
some
of
them
unfortunately
still
have
text
values.
This
cannot
always
be
avoided.
I
saw
a
bunch
of
new
text
values
there.
So
hi
yes,
so
we
are
considering
in
general
to
give
a
ad
for
compression
to
a
data
item
and,
as
you
are
concerned,
with
sighs
I
just
wanted
to
pitch
that
here,
I,
don't
think
if
it's
useful
or
should
be
scrapped
after
uttering
it.
It's
just.
H
The
combination
of
zebra
and
z4
was
also
used
for
the
DNS
aggregation,
benchmarking
thingy
and
from
the
icon
guys,
and
there
were
kind
of
fond
of
it
because
it
reduced
the
amount
of
data
significantly
depending
on
femicides
I'm,
not
sure
how
much
entropy
is
in
there.
It
might
not
matter,
but
this
is
my
first
comment
just
to
as
a
food
for
thought.
I'd.
H
Some
things
in
the
mind
to
ask
everywhere
so
just
I'm,
okay
with
that
and
and
they
don't
do-
it-
is
totally
fine
I'm
not
married
to
any
of
this
more
of
interest
to
be
right.
Now
is
the
second
question
I
have
in
in
second,
we
just
had
an
interesting
input
from
Kathleen
Moriarty,
because
the
coast
wid
seaboard
data
structure-
that
is
also
an
optional
item
of
the
suit
manifest-
was
proposed
as
I
was
proposal
from
Kathleen
to
make
that
a
CWT
structure
and
set
of
a
coastward
structure.
H
The
argument
here
was,
it
would
ease
adoption
of
the
data
structure
as
the
suit
manifest.
Basically
has
the
same
data
structure
as
the
coast
with
sea
bottom
I
would
like
to
ask
this
group:
would
you
see
any
obstacles
in
having
a
specific
suit
manifest
tag
instead
of
a
CWT
tag
in
front
of
the
manifest
map?
And
if
so,
is
that
a
realistic
threshold?
Or
is
this
just
a
a
felt
problem?
H
I,
don't
know,
I
really
don't
know,
because
I
would
think
that
if
you
make
anything
that
is
a
Siebel
map,
a
CWT,
you
always
inherit
all
the
CWT
normative
language,
which
also
includes,
for
example,
the
inclusion
of
all
the
seven
claims,
and
these
have
nothing
to
do
with
suit
manifests
and,
for
example,
they
have
nothing
to
do
with
a
course
which
software
identity
check.
And
so
my
question
is,
would
you
be
pro
or
con
tagging
this
suit
manifest
with
the
CWT
tech
for
the
sake
of
bigger
adoption
in
the
field.
H
A
E
H
C
H
D
H
E
C
A
And
this
is
the
list
of
stuff
that
came
up
in
the
t
p--
meeting
and
we
wanted
to
walk
through
these
briefly
and
get
a
yep
that's
already
in
there
or
nope.
We
got
to
do
something
to
add
that
okay,
so
I'm
going
to
walk
through
these
briefly-
and
this
is
really
the
only
slide
that
I
want
to
walk
through
unless
you
have
questions,
but
otherwise
this
is
my
only
slide
right,
and
so
let
me
just
prefix
this
by
saying.
A
So
let
me
walk
through
these
things,
because
earlier
in
this
meeting
we
said:
hey
the
suit
manifest
or
soft
right,
Nate
manifest
could
be
usable
for
a
larger
class
things.
You
know
updating,
Linux,
updating,
windows
or
whatever,
but
hey
has
anybody
gone
through
to
validates
that
would
actually
work?
Well,
that's
the
exercise
that
teep
just
did
for
a
trust,
execution
environment.
A
It
says,
would
it
actually
work-
and
this
is
the
list
that
we
came
up
with
in
the
teep
meeting
and
so
I'm
gonna
walk
through
each
of
these,
and
hopefully
we
can
say
this
is
already
there
or
it's
not
already
there,
but
it
could
be
easily
added
okay.
So
here's
the
four
things
the
first
one
is
to
say
for
any
dependency
from
a
particular
item
that
needs
to
be
installed
a
thing
that
has
a
manifest
any
dependency,
the
ability
to
list
one
or
more.
You
are
eyes
and
those
are
not.
A
You
are
eyes
where
the
binary
can
be
downloaded.
These
are
binaries,
for
which
you
can
use
a
protocol
to
negotiate
the
security
mechanism
needed
to
say,
get
the
decryption
key
or
whatever
else,
okay,
and
so
could
we
have
a
URI
associated
in
dependency?
That's
not
the
URI
for
the
binary
itself.
That's
point.
That's
number
one.
A
A
Trying
to
stay
in
ten
trying
to
stay
in
ten
minutes.
Okay
number:
two,
the
on
certain
types
of
te
es
there
is
in
order
to
install
the
binary.
You
have
to
do
a
particular
thing:
that's
to
create
this
security
domain
concept,
so
you
need
some
type
of
a
command
or
directive
of
whatever
it
says,
create
me
a
security
domain.
If
it
doesn't
already
exist
and
here's
the
ID
of
that
thing
there
we
just
need
to
be
a
way
to
express
that
in
the
manifest.
A
A
A
A
A
My
personal
belief
was
this
is
already
there
and
Brendan
talked
about
this
danger.
Meeting
I
just
wanted
to
confirm,
okay
and
then
the
last
one
is.
If
a
device
has
multiple
trusted
execution
environments
say
it
has,
you
know
SGA
exit,
TPM
and
whatever
else
attached
or
whatever,
then
you
can
indicate
which
one
of
those
Hardware
places
is
where
this
binary
should
be
installed
to
so.
E
A
Great
so
it
looks
like
we
have
maybe
too
easy
ads
and
two
things
that
should
already
be
possible.
We
just
have
to
confirm
and
it
works
great
in
an
implementation.
Thank
you.
That's
my
report.
Out
from
the
chief
working
group
sounds
like
we
can
use
it
just
fine
and
we
should
think
about.
We
Brendan
should
think
about,
should
we
would
it
make
sense
to
add
a
use
case,
template
for
ATP
use
case
or
not.
How
do
we
want
absolutely
okay,
all
right,
yeah
I'd
love
to
do
that?
All
right
great!
L
Good
afternoon
everyone,
my
name,
is
saya,
enjoy
and
I'm
studying
in
some
university,
and
this
is
my
third
time
participating
in
ITF.
Then
this
is
my
first
first
time
giving
a
presentation
in
ITF.
So
my
whole
body
parts
are
so
shivering
right
now,
but
it's
I
wanted
to
be
at
honor
to
stand
here,
and
this
is
my
first
step
of
my
work.
L
So
any
comments
or
feedback
sore
it'd
be
so
grateful
so
today,
I'd
like
to
discuss
about
a
distributed
for
suits
architecture
model
and
the
contents
of
today
slightly
traditional
suit
architecture,
proposal
and
next
step.
So
let's
see
the
traditional
suit
architecture.
L
First
then,
let
me
explain
my
proposal,
then
my
next
step,
so
the
traditional
suit
architecture
is
adopting
client-server
model
so
apparently
manifests
and
firmware
images
are
downloaded
from
firmware
servers.
So
the
picture
on
the
right
side
of
my
slide
is
exactly
from
the
architecture
stretched
of
suit,
and
there
is
a
server
in
between
author
and
former
consumer,
but
that
client-server
model,
which
is
which
has
centralized
architecture,
can
cause
overhead
on
servers
and
that
overhead
occur,
update
failures
and
also
servers
can
be
targeted
because
of
that
centralized
management
and
other
Authority.
L
So
it
can
be
targeted
by
an
attacker
for
using
an
attack
and
plus
we'd
like
to
define
a
new
issue
called
author
disappearing
issue,
which
is
literally
happens
when
an
other
authors
disappeared.
So
if
authors
disappeared
for
Amir's
consumers
who
have
not
yet
updated
to
the
latest
version
cannot
catch
up.
So
let
me
illustrate
the
author
disappearing
issue,
more
specifically
within
scenario,
so
maintenance
of
servers
as
dependent
on
the
author's
management
like,
for
example,
for
short
period,
work
for
a
long
period.
L
Others
could
be
disappeared
because
of
a
bankrupt
war,
an
attack
by
an
attacker,
and
for
that
period
they
cannot
manage
their
servers
and
servers
have
begun
after
that.
So
if
servers
are
unavailable,
of
course,
that
data
is
are
unavailable.
So,
in
that
case,
when
firmware
version,
4.0
is
uploaded
by
Ana
thought.
There
then
status
tracker,
giving
notice
to
a
consumer
that
they
have
to
get
updates,
and
after
that,
in
case
of
former
version
4,
it
can
be
update,
updated
completely,
but
in
case
of
former
version
5,
if
other
disappeared
after
they
uploaded,
consumers
cannot
download.
L
That
data,
even
after
the
authors,
disappeared.
So
my
proposed
architecture
is
just
like
this
and
former
server
in
original
architecture.
It
be
changed
to
blockchain
and
it's
gonna
have
distributed
storage,
and
that
is
gonna,
be
your
irreversible
and
it's
gonna
provide
high
availability
and
high
reliability
and
to
solve
bottleneck
problem
can
be
awkward
and
bulging
Network.
We
decided
to
have
registration
notes
and
retrieval
notes
and
registering
registration
notes
are
which
process
the
note
registrations
based
on
IP.
So
when
authors
wants
to
upload
their
primary
work
from
our
images
were
manifest.
L
L
Okay,
so
for
large
companies
producing
IOT
devices
and
have
it
be
better
to
have
private
blockchain
platform,
because
if
because
they
have
much
power
than
other
small
companies,
so
it'd
be
better
to
have
their
own
system
to
manage
them
and
small
medium
enterprises
with
higher
possibility
of
other
disappearing
issues
it
better
to
have
consortium
blockchain
platform,
because
even
if
they
have
disappeared,
other
disappear
issue.
The
nodes
connected
to
that
enterprise
could
be
connected
to
other
enterprises
that
managed
together
so
yeah.
This
are
two
architectures
that
can
be
adopted.
So
the
question
was
yes.
C
My
question
is
this:
is
Dave
Walter
Meyer
my
questions
on
this
this
model,
so
earlier,
when
you
were
presenting
I
was
wondering
you
know:
who's
gonna
host
this
blockchain
yeah.
So
for
large
companies.
Are
you
envisioning
that
that
would
be
used
in
a
case
where
different
parties
were
authoring
software
for
the
devices
that
those
large
companies
are
producing
or
were
the
large
company
be
the
author?
Because
if
the
use
case
is
to
to
protect
against
the
author
disappearing,
if
they're
hosting
their
own
blockchain
it'll
probably
disappear.
L
Yeah,
actually,
the
notes
constituting
the
blockchain
it'd,
be
not
only
authors
but
it'd
be
participants
who
want
to
be
that
well
notes
of
the
blockchain.
So
there
there
should
be
a
Ellis
management
of
author,
but
participants
normal
participants.
Users
gonna
have
that
data
too,
because
they're
gonna
be
the
users
and.
C
L
G
E
E
E
F
E
L
Yes,
because
yeah
blockchain
works
under
it
based
under
location,
works,
based
promise,
trolls
and
just
like
servers,
get
a
servers,
get
certificates.
It
data
just
like
just
same
things,
happen
in
blockchain,
because
notes
are
gonna,
can't
make
get
consent
notes,
are
gonna,
give
consensus
on
only
data
that
have
authorized
wave
certificates
so.
L
G
L
A
G
Richardson
so
I
I,
like
this
I
I,
like
the
concept
that
that
the
firmware
is
distributed
independently
of
the
authors
and
there's
a
number
of
groups.
The
the
secure
home
gateway
project
is
here,
labs
actually
wanted
to
have
exactly
that.
G
We
wanted
to
collect
all
of
the
firmware
from
all
the
devices
that
we've
ever
seen,
specifically
for
the
author
disappearing
case,
and
you
didn't
update
the
latest
thing
before
they
went
away,
and
so
this
is
really
interesting
and
I
think
that
a
little
bit
I
have
very
pessimistic
views
of
blockchain,
but
the
one
advantage
is
that
stuff
is
hard
to
delete
from
it,
and
so
you
can't
take
things
back
because
you
you
know
you
didn't
want.
You
didn't
mean
to
release
that
version
that
get
people
whatever
so
I.
Think
that's
a
really
interesting
thing.
L
C
M
Fast,
first
of
all,
you're
doing
a
great
job
for
your
first
IETF
present,
a
indeed
I
wanna
I,
want
to
I
want
to
agree
with
what
Brendan
and
Michael
said.
So
this
kind
of
things
been
done
before
it
reminds
me
of
like
distributed
file
systems
over
blockchain
like
interplanetary
file
system
stuff,
like
that.
It's
currently
in
use
for
for
stuff,
just
like
this,
for
maintaining
immutable
files
on
a
distributed
file
system
using
it
for
suit
is
cool,
and
there
are
some
use
cases
where
you
could
actually
do
that.
I.
M
D
This
is
honest:
I
was
wondering
about
one
thing
which
you
may
not
have
addressed
yet
is,
if
you,
if
there
also
disappears
the
other
problem,
is
what
happens
with
the
keys,
because
the
the
manifest
needs
to
be
verified.
So
that
also
has
the
private
key
and
unless
he
makes
that
available
to
someone
else,
you're
not
going
to
get
any
updates
in
the
future
anymore,
which
could
be
could
be
a
problem.
I.