►
From YouTube: IETF103-SUIT-20181108-0900
Description
SUIT meeting session at IETF103
2018/11/08 0900
https://datatracker.ietf.org/meeting/103/proceedings/
A
A
A
B
B
A
A
So
since
we
met
last
time,
we
adopted
an
architecture,
craft
and
information
model
craft
who
received
a
liaison
statement
from
I
to
UT
study
group
17
regarding
secure
update
about
UT
software.
We'll
talk
about
that
more
in
a
minute
and
a
hackathon
project
related
to
suit
one
on
it's
Saturday
and
Sunday,
and
of
this
week
at
the
Montreal
we
talked
about
possibly
having
an
interim
meeting.
The
cherubs
did
decided
not
to
pursue
them
in
our
meeting,
because
internet.
C
A
D
Yeah
they're
right
some
with
one
annotation
here
other
than
one
annotation.
This
is
the
slide
that
we
put
up
last
ITF
right.
So
all
the
rad
and
stuff
is
the
things
that
we
discussed
at
IAT
f-102,
and
so
we
had
agreement
on
those.
Although
there
was
this
question,
question
question:
if
you
look
at
the
Charter
milestones
that
are
still
posted
online,
they
haven't
been
updated
to
reflect
this.
Yes,
this
is
actually
the
more
authority.
Most
authoritative
version
is
what
was
on
the
slide
of
hf
102.
D
As
soon
as
the
architecture
document
is
updated,
then
we
can
actually
fill
that
in
and
work
with
our
80.
So
that's
our
update.
If
you
see
the
March
2018
is
in
red
because
we
haven't
adopted
any
manifest
serialization
formats
as
working
group
items
yet,
but
we
have
three
individual
submissions,
and
so
that's
part
of
the
point
of
the
meeting
today
is
to
focus
so
far.
We've
been
focusing
mostly
on
architecture
and
information
model,
and
they,
our
main
focus,
is
going
to
be
the
manifest
serialization
formats
and
at
the
end
of
the
agenda.
D
You'll
see
part
of
the
question
is
how
many
methis
formats
we
will
adopt,
because
our
Charter
allows
us
to
decide
whether
we
threw
it
out
without
one
or
more
than
one
we're
allowed
by
charter.
Okay,
and
so
we'll
have
some
presentations
about
that.
And
then
we
can
try
to
figure
out
what
the
right
date
to
replace
the
part
in
red
is
okay.
Otherwise,
you
can
see
the
submit
manifest
information
model
as
information
as
July
2018.
D
That
one
is
now
a
bit
overdue,
but
we
think
that
we
are
close
ish,
but
we
had
a
bunch
of
discussion.
Ietf
102
that
had
some
changes
that
have
been
made
yet,
and
so
we
don't
know
exactly
how
close
we
are,
but
we
think
that
there's
not
large
open
issues.
This
text
needs
to
be
done.
Okay,
are
there
any
questions
on
the
milestones?
That's
just
are
somewhere
of
where
we're
at.
D
D
Okay,
so
the
date
was
but
a
bottom.
Two
months
ago,
maybe
we've
gotten
the
A's
on
from
itu-t
standard
17.
As
you
may
recall,
we
got
only
a
sign
from
them
and
not
something
like
six
months
ago,
which
we
presented
in
a
previous
ITF
meeting,
and
so
this
was
the
slide
that
we
presented
then
or
I
presented.
Then
summarizing.
What
was
in
the
liaison
statement
fan
okay
back
then
they
did
not
send
us
the
actual
document.
D
D
E
D
Put
two
of
them
in
red
because
in
the
liaison
statement
now,
okay
I
want
to
show
the
deltas.
The
preference
in
black
is
basically
no
change
from
their
document,
because
this
time
they
sent
us
the
actual
document
for
us
to
review
okay,
and
so
that's
now
posted
on
the
liaison
cracker,
and
so
that's
the
URL.
If
you
want
to
read
their
full
document,
it's
about
I,
don't
know
18
pages
or
something
like
that.
You
can
find
their
actual
document
attached
to
that
liaison
there.
D
So
anybody
and
they're
working
to
can
read
it,
which
was
okay,
yeah
all
right.
This
is
what
they've
changed.
So
in
the
last
six
months,
they've
had
a
number
of
discussions
that
I'm
going
to
explain,
based
on
my
reading
of
that
18.
That's
okay
document,
okay,
so
the
one
of
the
bullets
on
the
previous
site
that
puts
in
the
previous
slide
are
the
ones
that
are
struck.
Fused
a
device
core
is
logically
renamed
a
firmware
consumer.
Okay,
as
far
as
I
can
tell
the
meaning
is
identical.
They
just
changed
the
name.
D
Okay,
the
second
thing
that
they
did
was
in
the
previous
slide.
I
go
back.
Let's
see
status,
tracker
and
communicator
and
the
previous
slide
right,
the
communicator
was
something
that
may
or
may
not
be
on
the
device
and
it's
what
keeps
track
of
the
status
of
the
device
and
it
initiates
the
update.
And
so
we
said
in
a
tiny,
tiny
constrained
device
it
might
not
be
resident
on
the
actual
microcontroller.
It
might
be
something
that
checks
the
microcontroller
and
initiates
the
update.
D
That
kind
of
thing
and
the
status
tracker
was
something
that
was
not
on
the
device
but
tracks
the
status
of
the
devices
under
its
administration.
Okay,
they
both
had
similar
well
similar
roles.
One
was
on
the
device
artifically
near
the
device
and
one
was
somewhere
else,
potentially
in
the
same
location
as
a
firmware
server,
there's
the
finest
for
different
roles
that
they
could,
in
theory,
all
four
be
on
separate
physical
devices.
Okay,
go
on
the
next
one,
so
what
they
did
not
show
their
diagrams
here,
as
they
said,
this
notion
of
status,
tracker
and
communicator.
D
That's
still
called
status
tracker,
okay,
those
two
were
combined
and
then
they
had
various
diagram,
so
I'll
go
on
and
I'll
show
you,
so
the
other
ones
are
the
same,
because
the
overall
question
at
the
end
of
this
is:
should
we
now
map
for
their
updated
thing,
so
I'm
going
to
walk
you
through
it?
You
know
a
full
screen
on
this
one.
D
Yeah
there
we
go
okay,
so
this
so
in
this
working
group
we
don't
do
protocol
procedure,
but
at
L
in
our
architecture,
we
talk
about
how
the
manifest
format
fits
into
a
larger
architecture.
They
also
don't
do
any
protocols,
but
they
do
try
to
have
an
architecture
diagram
that
says
how
things
fit
in
and
they
point
to
people
like
us
for
the
actual
technical
details.
So
this
is
their
architecture
that
shows
how
things
happen.
Okay,
so
here's
the
four
roles
at
the
top.
D
Now
they
added
an
author
role
which
wasn't
on
the
original
list
right,
that's
whatever
generates
the
firmware
event,
that's
another
role
that
we
kind
of
have,
but
was
something
there
from
the
original
list
right.
The
author
puts
a
firmware
image
up
on
a
firmware
server.
Okay,
they
had
a
status
tracker
which
may
or
may
not
be
on
the
device
that
check
status.
The
firmware
consumer
is
the
actual
device
right.
The
the
firmware
consumer
is
the
thing
that's
running
it
that
the
the
stuff
that
needs
to
be
installed
or
compete
the
place
okay.
D
So
it
checks
the
status
checks,
the
need
for
an
update,
initiates.
The
update
goes
and
grabs
the
firmware
image
from
the
firmware
server
and
so
on.
Okay,
so
here
the
status
tracker
is
not
shown
exactly
where
it
is
because
again
it
could
have
been
on
the
device
or
not
on
the
device.
So
this
is
the
overall
flow
that
they
assume
is
true
in
whatever
protocol
that
you're
using
and
again
they
don't
define
the
protocol.
This
is
just
the
overall
flow
stick
on
to
the
next
slide.
D
All
right
here
we
go
so
this
one
illustrates
one
of
the
reasons
why
they
come
by
okay,
so
here
on,
the
left
side
is
showing
a
devotee
device,
a
with
a
status
tracker
inside
it.
Okay
I
remember:
there
was
two
types
of
status
trackers
in
the
in
their
original
terminology,
the
one
that
was
potentially
on
the
device
and
the
one
that
was
somewhere
else,
maybe
close
to
the
firmware
server.
D
Okay,
this
is
showing
a
case
where
there's
a
status
tracker,
that's
inside
the
device,
so
join
that
case
and
it's
showing
another
case
near
the
bottom
there,
whether
the
status
tracker
this
near
but
outside
of
devices,
B
and
C.
Okay,
so
it
may
or
may
not
be
on
the
device.
Okay,
and
so
this
is
showing
other
roles,
the
author
and
the
firmware
server.
Okay,
okay,
there's
a
more
complicated
one
that
shows
the
status
tracker
here.
D
I
didn't
include
this
diagram
and
it's
there
in
the
document,
but
the
status
tracker,
that's
inside
in
the
middle
left
there
that
one
is
conceptually
sitting
over
here
and
they
have
more
complicated
ones.
With
this
change
status
track
is
one
status
track
of
the
tracks,
another
one
and
so
on.
They
said:
there's
this
general
functionality
to
track
the
status
from
something
else
which
could
be
a
defer
more
consumer,
or
in
this
case
you
can
see
how
the
status
trackers
are
chained
right.
This
status
tractor
checks
the
status
and
this
one.
D
These
two
rights
here
were
the
ones
that
previously
had
the
different
names.
Okay,
they
said
the
role
is
the
same:
it's
checking
the
status
of
something
on
that
something's,
a
firmer
consumer
at
the
center
there
it's
another
status
tractor,
so
they
just
change
these
to
use
the
same
name,
because
it's
motion
tracking
the
status
initiating
update.
They
said
that's
similar
enough.
It
doesn't
make
sense
to
use
two
different
terms
for
that.
D
Okay,
given
that
this
was
already
possible
to
not
be
on
the
device
okay,
so
this
notion
of
chaining
is
the
discussion
they
apparently
had
and
that's
what
led
them
to
say.
We
don't
need
for
terms
for
if
you
only
for
the
original
terms,
we
don't
we
only
for
three
of
your
regional
terms,
so
that
was
the
main
difference
in
what
their
liaison
statement
was
ranked.
Here's
some
work
that
we've
done
over
the
last
six
months,
and
this
was
the
main
change
that
they
did
with
this
terminology
change
and
the
architecture
shot
here.
D
Okay,
so
here
we
go,
it
still
intentionally
does
not
define
any
protocols
or
formats.
In
fact
they
explicitly
in
their
document
reference
us,
here's,
the
quote
and
their
document.
It
says
note
that
the
IETF
suit
working
group
is
currently
working
on
the
format
of
manifest
and
firmware
update
procedure
using
the
manifest
okay
that
was
they're,
not
saying
you're,
not
going
to
do
the
work
they're
explicitly
looking
to
us
to
do
that
work.
D
It
also
has
references
to
two
other
documents
or
two
other
things
activities
and
explicitly
rash
references,
the
IOT
security
update
workshop
and
it
explicitly
references
one
end
to
M
at
examples
of
other
other
work
in
this
area
that
itu-t
sub-17
is
not
going
to
do
because
these
other
groups
are
already
actively
looking
at
this.
This
does.
Their
document
does
in
fact
design
requirements
for
each
of
those
roles
right
the
status
tracker
and
some
were
concerned,
the
clients,
here's
the
requirements
for
those
okay.
Now
my
reading
feel
free
to
read
it
yourself.
D
My
reading
is
that
their
requirements
are
consistent
with
our
requirements
that
we
have
in
our
architecture
and
information
model
document.
Okay,
unless
I
miss
something
I
think
that
they
are
consistent,
it
just
phrased
differently
or
whatever,
but
I
think
that
they
are
indeed
already
consistent.
I
couldn't
immediately
spot
something:
oh
yeah,
here's
something
we
need
to
address
on
it.
E
Do
seek
a
community
key.
Thank
you
very
much
for
discussing
this.
I
am
the
first
extended
gears
on
statement
and
I'm
attending
suit
every
time.
So
in
the
previous
question
suits
people
said
that
you
want
to
keep
alignment.
The
terminology
I,
isn't
that
so
from
outside
I
mean
I'm
talking
from
IT
design,
I
decided
to
keep
track
on
suit
and
try
to
keep
consistency
with
you
and
also
on
Christian
Excel
is
in
the
previous
meeting.
E
You
sit
instructor
before
I
go
a
lot
of
the
term,
but
he
made
it,
but
he
added
and
maybe
personage
who
said
sit
instructor
was
not
a
main
component
of
athlete.
A
draft
at
a
time.
So
I
do
TSI
ecstatic
to
develop
more
upon.
That
sits,
say
the
trucker,
but
if
the
director
is
one,
the
main
focus
of
this
wacky
group
I
would
prefer
to
discuss
here
rather
than
there.
So
I
am
looking
forward
to
the
discussion,
how
it
goes
and
reverse.
E
D
Thank
you,
okay,
so
I
guess
I
should
ask.
Besides
the
two
of
us,
can
I
get
another
volunteer
to
read
the
document
and
look
for
anything
else
that
we
might
actually
want
the
change
in
our
document,
since
there
wasn't
anything
raised
on
statement,
says
here.
Please
change
this
hey
Hannes!
Thank
you
for
the
great
again
more
people
confirming
that
it's
already
consistent
is
good.
Thank
you
all
right.
So
the
here's,
our
three
questions.
D
There
are
similar
the
questions
that
we
asked
at
our
inter
meeting
when
we
reviewed
the
first
interim
state
first
gaze
on
statement,
but
I'll
ask
them
explicitly.
Should
we
update
our
architecture
document
to
be
consistent
with
a
set
of
group
17
document?
Currently
we
updated
it
to
match
the
same
language
as
in
the
old
liaison
statement
should
be
updated
to
match
the
new
terminology
that
they
have
and
it's
the
first
question.
Okay
I
ask
that
right
now,
I
see
one
person
who's
an
editor
nodding.
D
D
I
understand
so
that
if
the
terminology
changes
will
ring,
you
review
this,
but
I
think
that
the
discussion
that
says
that
the
difference
between
the
old
key
terms
admire
enough
to
try
to
combine
those
into
our
role
that
can
be
chained
and
so
on.
I
think
is
a
my
reading
of
what
was
that
was
a
valuable
contribution
so
as
a
that
speaking
as
an
individual.
So
so.
E
D
Goes
to
RFC,
then
we
can't
change
it.
So
you
know
that
yeah.
Okay,
second
question:
there
document
explicitly
references
us,
although
it
doesn't
reference
a
document,
it
references
the
working
group,
because
what
I
have
an
RFC
or
anything.
So
the
question
is:
should
we
add
an
affirmative
reference
to
the
s
g17
document
to
specifically
say
that
they're
consistent?
D
G
D
D
Yeah
good
point,
okay
and
that
the
third
question
is:
is
there
any
reason
that
we
need
to
respond,
given
that
we
have
representative
here
in
the
room
and
the
vase
on
statement
did
not
explicitly
ask
us
a
question
per
se?
If
you
know
we
look
forward
to
working
with
you
and
so
on,
which
is
great,
and
so
in
the
previous
one
we
did
not
see
a
need
to
explicitly
respond.
D
We
just
it
worked
right,
and
so
is
there
any
reason
that
we
need
to
explicitly
respond,
or
is
just
the
fact
that
you
know
he's
here
in
the
meeting
and
he
can
carry
back
the
the
discussion
we
have.
Is
that
sufficient
I
don't
see
a
need
to
respond,
as
anybody
thinks
there's
need
to
respond,
but
not
okay,
then
we're
down
to
this
item
great.
H
Dave
Robin
Wilton
to
make
something
that
doesn't
necessarily
need
to
be
reflected
in
doctrine,
at
least
in
my
view,
but
something
that
we
should
have
to
think
about
is
this
idea
of
chained
status.
Truckers
I
can
see
how
conceptually
a
state
destructor
is
a
state
instructor
as
a
state
instructor,
but
on
the
other
hand,
I
can
also
see
how
the
status
tracker
at
the
bottom
of
a
chain
might
be
functionally
somewhat
different
from
the
state
instructor.
E
F
F
Here
was
the
wiring
of
the
internet,
so
we
had
a
larger
group
and
I
listed
a
couple
of
the
names
here.
It
was
difficult
to
take
a
picture
of
everyone
because
people
sort
of
ran
in
and
out
somehow,
but
we
also
had
a
few
first-timers
and
some
of
them
actually
didn't
stay
for
that
for
the
ITF
meeting
insert
they
just
stayed
for
the
hackathon
others
I
encourage
everyone
to
participate.
In
fact,
if
only
because
there's
a
lot
of
fun
at
least
on
the
second
day,
the
first
day
is
also
moved
into.
F
What
we
also
had
was
a
lot
of
hardware
to
play
with.
We
have
this
a
custom
suit
board
created
with
the
last
time
already,
which
we
took
with
us,
and
what
was
new
is
one
group
that
joined
us
for
the
first
time
in
this
suit.
Hackathon
took
a
special
Renaissance
sport
with
them,
which
used
hardware
security
and
required
an
encrypted
firmware
image.
So
there
was
a
subtle
variation
in
what
we
were
doing
and
so
here's
what
we,
what
we
did
at
the
hackathon.
F
Unsurprisingly,
we
use
we
had
a
Python
tool
and
you
can
actually,
at
the
end
of
the
slide
deck.
You
can
see,
pointers
on
what
we
did,
because
we
wrote
down
a
few
notes
or
hey
me
did
in
sort
of
like
if
you
want
to
reproduce
some
of
those
steps.
Of
course,
we
set
up
the
holding
development
environment
and
many
of
us
did
have
the
FAQ
console.
Video
account
welcome
to
staff
that
are,
if
a
day
basis,
so
that
wasn't
much
effort,
but
amy
was
kind
enough
to
produce
a
doc
rice
development
environment.
F
So
if
you,
you
guys
want
to
get
some
of
this
working
yourself,
there's
actually
now
the
bar
to
get
started
is
actually
very
low.
So
you
kick
off
a
doctor,
containment
and
you're
good
to
go
so
that
poor,
embed,
OS
and
riot
in
in
the
use
domenica
stool,
that
Brendon
has
been
working
on
and
and
was
extended
for
this
hackathon
to
generate
or
to
write
the
manifest
in
a
chase
on
paste
format,
because
it's
obviously
nicer
and
then
use
that
as
an
input
to
produce
a
manifest
in
the
Seaboard
Cosi
based
sign.
F
I
think
that
was
him.
He
worked
us
on
a
CDL
based
version,
so
we
had
a
cup
of
different
choices
on
how
to
create
the
manifest
and
then,
of
course,
we
had
to
then
take
manifests
in
the
firmware
up
to
the
port
itself.
And
unsurprisingly,
we
had
a
couple
of
different
options
that
we
use
and
from
usb
to
just
dumping
the
stuff
in
the
tailing,
through
some
memory
region
or
to
use
co-op
and
so
on
so
different
ways,
and
then.
F
Yeah
I
didn't
I,
didn't
show
that
slide
at
the
so
some
of
those
slides
are
were
used
at
the
hackathon
presentation
at
the
end,
to
inform
the
participants
of
what
we
were
actually
doing,
but
I
keep
them
up
a
little
bit
to
provide
a
little
bit
more
context
on
what
we
really
did
so
I
hope.
You
appreciate
that
one
of
the
things
that
you
obviously
have
to
go
through
when
you
work
on
hard
ways.
You
actually
need
to
configure
the
your
system
properly,
so
they're
different,
microcontroller
manifacturers.
F
They
they
provide
different
tools
to
come
figure
you
our
microcontroller
properly,
and
so
in
my
case
and
that's
why
I
took
the
screenshot
from
I
used
STMicroelectronics
and
for
this
from
my
examples,
and
so
you
can,
as
you
can
see
in
the
color
coding
of
this
microcontroller,
you
can
actually
change
the
whole
pin
layout.
You
can
enable
and
disable
features
of
the
microcontroller,
which
is
then
nice,
because
you
exactly
enable
the
features
that
you
want
to
reduce
the
code
size
and
you
you
can
work
with.
F
If
you,
for
example,
we
can
play
or
we
labor
they're
big
names,
you
can
actually
work
with
symbolic
names-
have
a
look
at
this
yourself
and
there's
a
totally
key
that
you
can
download,
I
and
I.
Think
it's
a
an
insightful
exercise.
If
you
are
like
me
like
in
the
past,
like
to
work
on
overclocking
your
desktop,
you
see,
you
will
appreciate
that
functionality,
it's
basically
overclocking
on
steroids,
because
you
can
literally
change
everything
in
the
processor
but
exciting
and
of
course,
that's
the
maybe
not
so
fun
part.
F
That
update
is
to
talk
a
little
bit
about
the
bootloader
and
what
the
role
of
the
bootloader
is
and
how
does
it
fit
into
the
whole
context
in,
in
our
case,
the
bootloader
was
very
minimalistic
and
we
only
had
one
foot
loader.
So
there's
no
stage
2
bootloader
and
that
bootloader
was
ordered
responsibility.
If
the
bootloader
is
good,
it
gets
executed
or
I
started
whenever
you
turn
the
device
on
and
then
it
needs
to
make
a
decision
about
what
image
to
start.
F
So,
in
our
case,
we
also
done
the
security,
the
suit
manifest
passing
into
that
bootloader,
and
also
some
minimalistic
functionality
on
how
to
actually
access
the
the
image.
So
in
case
of
the
USP
delivery
that
I
mentioned
before,
you
obviously
need
to
attach
the
firmware
from
the
USP.
So
you
need
to
have
that
implementation
in
there
as
well.
F
So
there
are
different
design
choices
on
how
you
implement
to
hold
this
whole
architecture,
which
obviously
has
some
security
implemented
implications,
and
we,
we
picked
a
very
sort
of
basic
approach
here,
which
may
not
be
the
best
one
but
I
think
in
discussions
in
earlier
meetings.
I
think
that
was
that
was
type
of
information
and
design
choices
that
people
wanted
to
see
in
also
captured
in
the
architecture
document,
and
for
that
purpose.
I
talked
to
one
sort
of
found
in
this
expert
checkup
an
Ingo
three
weeks
ago.
F
To
help
me
work
on
those
options
because
he
obviously
has
more
experience
in
sort
of
seeing
what
the
wider
industry
does
in
the
bootloader
different
okay.
So
what
you
see
here
is
that
you
have
flash
memory
which
is
on
chip
and
there
are
different
sectors,
so
you
typically
erase
sectors
entirely
and-
and
it
starts
in
this
memory-
address
that
you
can
see
up
here,
and
so
that's
and
I
was
showing
the
next
slide.
F
First,
the
application
is
actually
in
another
slot
and
and
also
it
executes
the
application
we
really
want
to
execute,
and
then
we
use
a
separate
area
for
the
firmware
that
we
want
to
update
so
there's
some
space
that
basically
is
eaten
up
by
having
this
of
having
more
than
one
image.
But
otherwise,
if
you
mess
it
up,
you
essentially
prettier.
I
F
Tunnel
into
some
details,
and
so
what
you
find
on
on
these
microcontrollers,
it's
for
the
vector
table,
and
you
see
that
there's
this
is
the
vector
table.
It's
just
a
bunch
of
addresses,
so
it
starts
at
this
address
and
in
if
you
look
back
so
this
is
essentially
address
0,
but
you
have
to
see
it
in
context
of
where
the
code
actually
starts.
F
So
it's
this
address
really
and
the
first
there's
one
sort
of
research
field,
which
is
the
stack
pointer
and
then
the
vector
table
essentially
contains
just
a
lot
of
pointers
to
functions,
and
this
is
the
reset
and
it's
the
first
function,
and
then
there
are
many
others
sort
of
processor.
If
it
it
boots,
then
it
jumps
to
the
reset
reset
vector.
Of
course,
if
we,
then,
if
we
have
two
images,
they
are
obviously
the
processor
doesn't
know
where
our
application
image
is.
F
So
it
jumps
to
the
space
where
the
bootloader
is,
and
here
I
so
code
example
on
how
you
actually
write
the
bootloader
to
make
the
necessary
steps
to
jump
to
the
from
after
the
actual
application
firmware.
So
what
it
does
is
and
I'm
not
going
to
into
the
details,
but
it's
actually
quite
simple:
you
need
to
configure
the
stack
pointer
which
is
at
this
address
0.
You
need
to
read
this.
F
The
reset
handler
address,
which
is
32
bits
later,
as
I,
showed
you
choice
on
the
last
slide
you
this
is
your
function,
your
function
pointer
and
you
jump
to
that
function,
pointer
address
and
then
your
application
image
start
it's
something
that
we
had
to
go
through
in
our
in
our
hackathon
example,
when
we,
when
we
worked
on
this,
just
to
give
you
a
flavor
of
what
we
were
actually
doing,
we
didn't
write
any
assembly
code.
This
is
all
C.
F
So
what
did
we
learn
and
like
the
first
day
as
I
said,
it's
always
very
difficult,
because
you
need
to
get
things
working
and
there's
always
something
that
goes
wrong
before
the
hackathon
type
into
there's,
always
some
problem
and
so
which
we
try
and
shop
with
it,
but
also-
and
that
was
really
cool,
because
we
had
a
couple
of
experts
in
that
remains
in
the
same
room
and
sitting
in
the
next
table.
F
We
also
found
out,
as
part
of
thumb,
this
exercise
that
we,
we
had
messed
up
some
CDL
and
examples
in
the
in
a
manifest
document,
so
we
need
to
fix
them
and
what
actually
Hank
has
already
worked
on
on
it
and
can
see
it
so
to
to
actually
get
it
corrected,
of
course,
will
ultimately
depend
on
what
the
group
wants
during
this
meeting,
but
I
think
we
step-by-step.
We
get
there
to
working
sittig
a
working
example,
yeah.
I
F
Yeah
submit
it
for
with
you,
just
kidding,
yeah
and
almost
forgot
so
or
that
here
the
last
hackathon
sort
of
the
people
in
the
room
who
worked
on
the
different
projects,
but
then
again
asked
to
sort
of
get
their
recommendation
for
specific
project
a
like
most
and
funny
enough.
They
picked
us,
and
so
so
we're
quite
surprised
about
this.
Thank
you.
Buddy.
F
F
We
can
look
up
the
details
and
and
the
write-up,
and
there
are
pointers
to
previous
write
ups
as
well,
so
you
can
reproduce
it
but
don't
be
hesitant
to
just
approach
any
one
of
us
and
we're
happy
to
help
and
give
you
so
much
a
what
if
point
us
to
the
tools
that
we
will
be
using
and
also
their
support,
and
so
on.
Okay,.
J
D
F
So
short,
summary
on
the
architecture:
information
model
that
there
was
this
one
open
issue
in
the
architecture
document
and
to
talk
about
thought
of
it,
please
what
I
just
elaborated
on,
so
we
still
have
to
work
on
text
I'm,
relying
on
this
industry
expert
to
help
me
do
that
haven't
done
that
yet
so
I
hope
to.
But
we
haven't
come
up
with
the
text,
yet
I
hope
to
do
that.
I
hope,
like
from
the
explanation
I,
provided
you
just
a
few
minutes
ago.
F
I
hope
that's
what
you
were
looking
for
when
we,
when
you
talk
about,
give
us
or
give
us
more
text
about
the
bootloader,
that
is
the
type
of
content.
I
was
thinking
about,
seeing
staged
multiple
states
put
load
about
to
put
in
his
boot
loader
and
from
this
type
of
design
consideration.
It's
not
nothing
really
that
it
has
security
implemented
implications
its
but
its
implementation
choice.
It's
not
a
controllability
issue
in
my
opinion,
but
yeah
still
still
some
confusion.
It.
D
Have
helped
to
set
the
context
for
the
architecture
and
help
people
understand,
the
requirements
have
been
appear
in
the
information
model,
and
so
I
think
that
the
task
is
to
make
sure
that
the
discussion
is
generic
enough,
that
it
applies
to
many
types
of
processors,
and
so
there's
that
other
people
that
watch
the
ionises
presentation
about
the
bootloader
stuff.
That
said,
oh
well,
you
know
my
dealer
door
doesn't
work
that
way.
Then
please
comment
and
help
proposed
text.
We
can
make
sure
the
text
is
generic
enough.
D
What
we
need
cover
more
than
one
use
case
or
just
have
one
description,
is
generic
enough
to
cover
all
the
cases
we'll
see.
I
think
that
was
part
of
the
point
in
discussing
it
now
is
to
say
this
is
the
style
of
stuff
for
the
hollow
should
be
putting
into
the
text
if
this
makes
sense,
but
to
make
sure
it's
like
an
ax
stuff
that
you
walk
through.
That
was
the
SG
micro
example
of
the
bootloader
and
even.
D
F
F
So
besides
that
I
don't
think
the
open
issues
with
the
architecture
document
on
the
information
model
document
and
Dave
was
kind
enough
to
point
me
to
the
meeting
minutes
from
from
last
meeting
from
the
last
idea
meeting
to
illustrate
that
we
had
some
open
issues
there
and
the
open
issues
were
sort
of
the
alignment
with
the
manifest
works.
So
it
turns
out
that
back
then
we
didn't
use
different
or
we
use
different
terms
for
some
of
the
elements
in
the
manifest
compared
to
the
information
model.
F
Funny
enough,
we
based
on
the
discussion
at
the
last
IDF
meeting.
We
changed
the
names
again
so
so,
if
we
essentially
kept
one
one
update,
so
we
now
need
to
figure
out
when
we
talked
about
the
money
tests
later
on,
like
what
what
the
terms
finally
should
be,
and
we
should
or
didn't
get
them
in
sync.
I
hope
that
we
can
settle
on
the
terminology
now
on
the
terms
that
we
use
for
the
different
elements
in
the
manifest.
So
we
don't
have
a
disconnect
here,
but
yeah
alignment
is.
D
J
I
have
a
few
notes
left
over
and
the
last
time
we
discussed
the
information
model.
What
I've
got
in
addition
to
what
hannises
mentioned
is
a
couple
of
to-do
items,
namely
the
forward
references
for
the
threat
model,
so
that
every
element
you
can
work,
walk
through
either
forwards
or
backwards,
either
from
the
problem
that
it
solves
to
this.
The
security
requirement
that
creates
to
the
the
element
in
the
manifest
that
solves
that
or
the
reverse
working
backwards
from
each
element
and
seeing
why
it's
there.
J
The
second
item
I've
got
is
that
if
there's
an
explanation
needed
that
explains
the
threat
model
is
incomplete
and
that
there
are
many
elements
of
the
of
a
system
threat
model
that
aren't
actually
in
there.
For
example,
there
are
no
physical
attacks
listed
in
the
in
big
threat
model
there
and,
finally,
that
there's
needs
to
be
a
possibility
of
counter
signing
manifests,
rather
than
linking
them.
I
think
that
might
have
been
on
the
on
the
manifest
side
of
things
rather
than
in
the
information
model.
L
Inclusive
would
draw
a
center
point
of
attend
Society,
so
just
wanted
to
inquire
about
that.
As
of
one
solar
discussion
thread
on
the
mailing
list
with,
in
my
opinion,
the
manifest
and
the
form
where,
in
fact
the
manifest
contains
more
information
than
the
phone
with
image.
So
it
when
we
talk
about
its
encryption
and
security
properties
of
transporting
that
that
it
should
get
the
same
treatment
as
the
firmware
image.
So
just
wanted
to
inquire
about
well.
F
Honey
yeah
I
remember
that
discussion
I
thought
to
be
puts
on
text
in
India
to
talk
about
this
I'm.
F
The
signing
and
encryption
capabilities
of
the
manifest,
as
well
as
as
the
firmware
since
imposed
obviously
contain
different
information,
but
post
is
quite
valuable
information
and,
as
we've
seen
also
that
this
hackathon
some
of
the
hardware
actually
requires
you
to
use
encrypted,
manifests
encrypted
for
more
images,
so
so
I
and
also
I,
think
I'm,
not
saying
anything
wrong,
but
we
didn't
test
it
that
the
hacker
man
that
the
manifest
format
can
also
be
encrypted,
so
we
yeah,
but
we
should
double
check.
Did
you?
Did
you
double
check
on
the
weather?
J
Believe
that
the
resolution
that
was
proposed
on
the
mailing
list
was
that
this
was
a
good
use
for
transport
encryption
rather
than
necessarily
at
rest
encryption,
and
there
are
a
number
of
difficulties
with
going
forward
with
at
rest.
Encryption
of
the
manifest,
not
least
among
them,
is
that
this
severely
limits
your
ability
to
use
this
format
in
a
broadcast
environment.
Since
the
proposal
was
that
it
would
be
the
component
which
defines
how
to
obtain
the
key
for
the
at
rest,
encryption
of
the
firmware.
J
There
are
a
few
ways
we
can
work
around
this
and
there
are
some
components
that
could
be
encrypted
to
just
solve
the
problem,
but
it
seems
to
me
that
there's
going
to
be
quite
a
lot
of
difficulty
in
doing
at
rest,
encryption
of
the
manifest
itself
I'm,
not
saying
we
can't
do
it
and
we
should
probably
add
some
more
text
to
that
effect.
But
I
think
that
it
adds
a
lot
of
difficulty.
That's
not
necessary.
If
transport
encryption
is
adequate.
F
L
G
I
D
J
D
I
B
Their
exam
right,
so
I
thought
they
started
with
wanting
to
encrypt.
The
image.
Did
I
miss
that,
because
right
now
what
people
have
have
implemented
is
the
image
being
embedded
in
the
manifest,
which
is
fine,
but
we
also
have
the
ability
to
have
the
image
be
external
right
and,
if
I
care
about
scale-
and
oh,
maybe
about
this
encrypted
images.
Or
this
make
it
the
external
and
you
can
get
the
manifest
but
the
image
and
can
contain
keys
for
the
image
to
suffer.
B
F
One
is
yeah,
it's
correct
that
we
initially
started
off
with
encrypting
the
former,
which
was
what
are
optionally,
so
it's
not
mandatory
to
encrypt
it
from
where
unwanted
India,
which
I
see
as
Assad,
know
how
the
image
is
actually
pushed
along
to
the
device,
whether
it's
attached
to
it
or
whether
that's
sort
of
sent
separately.
F
But
then
we
went
on
in
the
discussion,
and
that
was
what
the
review
was
about
was
should
be
actually
or
how
do
we
protect
some
of
the
contents
of
the
manifest
itself
because
they
may
be,
there
may
be
some
privacy
of
relative.
If
is
there?
That's
that's
what
that's
why
this
discussion
on
the
mailing
list
came
from.
D
Even
if
there's
nothing
else
on
the
in
architecture,
information
models
we're
not
going
to
move
into
that
part
of
the
agenda
about
actual
serialization
formats,
and
so
there's
some
background
here.
As
a
reminder,
a
charter
allows
us,
should
we
choose
to
do
so
to
work
on
more
than
one
serialization
format,
or
it
allows
us
to
choose
to
only
pick
one
and
so
right
now
there
are
at
least
three
individual
documents,
two
of
which
are
variations
of
Seaborn
and
one
of
which
is
binary
in
the
past.
D
When
we
first
started
this
session,
there
was
another
proposal
that
was
asn.1
based,
and
so
part
of
this
has
to
do
with.
What's
the
choice
of
basic
encoding
mechanism
for
encoding
mechanisms
and
we'll
come
back
to
that
question
after
these,
and
so
we'll
have
people
talk
about
the
different
individual
documents
right
now
and
all
for
whether
there's
working
through
interest
in
adopting
it.
D
This
is
sort
of
in
scope
for
this
discussion,
especially
as
getting
into
question
number
seven,
which
is
really
deciding
how
many
do
you
want
to
adopt
and
so
that
slowly
will
actually
ask
those
questions.
Okay,
and
so
we
have
Hank
and
Brendan
and
Merton
Brendon
and
Martin
will
be
regular
presentations
and
Pinkerton
like
right
now
and
so
I
will
let
you
spread
it
out.
Our.
D
K
Most
nights:
this
is
Hank
not
from
the
floor,
but
at
the
mic
attendee,
so
we,
the
draft
name,
says
it
all.
This
is
a
subset
of
concise.
Soft
identifiers,
so
suffered.
Amplifiers
are
ISO
standard
and
we
are
we
molding
that
into
something
more
concise,
inconsistent
and
that
is
called
concise,
soft
identifiers
in
the
area
and
there
are
resource
collection
there
and
we
wanted
not
only
to
be
able
to
talk
about
standard
software
components
but
also
or
film
there.
K
So
why
am
I
telling
you
all
this
and
the
suit
manifest
in
the
last
iteration
was
a
set
of
array
element
ever
nested
and
and
in
the
concise
softer
than
the
fire
is
an
abstraction,
but
also
nested.
So
by
the
change
of
encoding
method.
With
the
current
manifest
from
Brandon,
it
is
probably
obsolete
to
continue
the
specific
code
suet
version,
and
my
hope
is
that
we
can
just
converge
in
a
way
that
it's
just
naturally
fitting
into
each
other.
K
D
J
So
these
are
our.
This
is
a
brief
summary
of,
what's
in
the
new
version
of
this
manifest,
if
you've
had
a
look
at
it,
it's
quite
a
large
document
and
most
of
it
wasn't
there
in
the
previous
version,
so
there's
an
enormous
amount
in
there
and
with
that
in
mind,
I'm
going
to
hit
the
highlights
as
much
as
I
can,
and
hopefully
we
can
have
some
good
discussion
more
about
this
on
the
mailing
list.
I
think
there's
probably
too
much
to
cover
in
the
meeting.
J
So
there
are
a
lot
of
changes.
A
lot
of
it
came
from
the
meetings,
the
mailing
list
and
a
bit
of
information
from
the
hackathon
and
I've
proposed
Eiko's
a
digest,
structure
and
I'll
need
to
talk
a
bit
more
about
that
in
a
minute
and
there's
a
big
new
feature
of
severable
fields.
This
is
particularly
relevant
for
text
components,
because
text,
of
course,
can
be
very
large
and
we
want
these
manifests
to
be
very
small,
so
being
able
to
trim.
Some
components
is
important.
J
Okay,
so
because
a
digest
is
a
concept
I've
proposed
in
the
manifest
I've
gotten
some
feedback
from
Jim
Chad
in
case
he's
not
in
the
room,
and
that
suggests
that
perhaps
this
is
too
heavy
weight
for
our
use
and
a
simpler
solution
would
be
a
better
choice.
So
I
think
that
that
warrants
further
discussion
in
this
case,
what
I?
What
I
proposed
in
the
document
says
essentially
that
we
reuse
the
cozy
max
structure,
replace
the
the
tag
or
the
Mac
with
a
digest
and
use
the
context
of
digest
instead
of
Max
zero
next
slide.
J
Please-
and
this
is
just
the
CD
DL
that
describes
what
would
be
used
to
accomplish
that
nothing
terribly
surprising
here.
I
expect
so,
given
that
there's
already
been
some
commentary
from
the
cosy
or
one
of
the
cozy,
otters
and
I
think
that
we
should
probably
continue
that
discussion
at
a
later
time,
possibly
in
the
mailing
list.
J
J
Okay,
so
I'm
going
to
go
through
the
manifest
building
it
up
gradually
in
examples
here,
so
that
we
can
have
an
idea
of
exactly
what's
being
encoded,
how
it's
encoded
and
what
the
cost
is.
So
if
we
start
with
this
first
example,
the
idea
here
is
that
this
is
essentially
a
wrapper
for
a
payload.
It's
got
very
little
information
in
it.
In
fact,
we're
only
encoding,
37
bytes
worth
of
actual
information
that
we
want.
The
encoding
in
C
Seaborg
gives
takes
us
67,
bytes
and
the
way
that's
all
packed
is
in
the
next
slide.
J
J
Next
slide,
please
so
a
second
example:
now
this
one
is
signed,
but
beyond
that,
it's
the
same,
as
example
one
next
please
so
this
is
primarily
just
adding
on
echoes
a
sign
object,
and
it
is
exactly
what
you'd
expect
to
find
in
a
normal
hose.
A
sign
object
next
place
and
yeah
good
enough.
Okay.
So
now
example:
three
here
we
have
the
same
sign
a
signature
system
and
a
little
bit
more
information
to
encode.
J
Here
we
have
a
payload
URI
or
if
you
obtain
it,
we
have
preconditions
which
kind
of
hardware
this
would
match
and
we
have
a
text
description.
So
now,
we've
gone
up
to
four
hundred
and
twenty
eight
bytes
of
actual
information
that
we're
trying
to
encode
and
the
encoded
size
is
six
hundred
and
five
bytes.
The
this
also
showcases
the
point
of
being
able
to
prune
elements.
J
J
Next,
please
and
then
the
text
information
which
consists
of
a
tag
of
a
key
of
one
meaning,
update
description
and
200
bytes
worth
of
text
next,
please,
and
for
the
fourth
example,
it's
again
the
same
thing,
but
in
this
case
it's
using
a
B
SDF
decompression,
rather
than
using
the
sorry,
rather
than
using
a
broad
binary.
Next,
please.
J
So
here
the
installation
information
is
the
most
important
part
and
it
shows
a
list
of
three
separate
processors.
This
time
around
the
first
one
obtains
the
remote
resource
from
a
URI,
as
described
in
the
previous
example.
The
second
shows
where
to
obtain
a
local
copy
to
diff
against
the
local
resource,
and
then
the
third
shows
using
a
BS,
diff,
unpacking
algorithm
and
what
it
should
use
as
its
inputs,
in
this
case,
using
the
remote
resource
as
the
as
the
diff
input
and
the
local
resource
as
the
local
reference,
and
that's
about
it.
J
Now
this
is
what
leads
to
the
different
objects
being
grouped
together
and
being
able
to
to
separate
some
components
after
they're
used.
The
lifecycle
is
essentially
the
process
of
what
components
are
needed
in
the
manifest
throughout
its
distribution
and
consumption.
So
first
text
is
needed
when
humans
are
involved,
but
once
a
manifest
is
dispatched
to
a
device
that
can
be
removed
since
devices.
If
they
present
information,
don't
need
that
information,
then.
The
next
thing
is
the
set
of
pre
installation
information,
which
includes
preconditions
and
pre
directives,
and
those
can
be
pruned
when
they're.
J
No
longer
needed
and
the
the
process
continues
that
way
to
allow
us
to
remove
and
information
when
it's
no
longer
needed
by
the
end,
node
I've
added
some
more
preconditions
and
pre
directives.
There
are
a
few
left
to
add:
I
removed
the
processing
graph
that
I
described
in
the
version
2
draft
because
it
seemed
like
it
was
going
to
require
more
processing
than
was
necessary
on
constraint,
nodes.
D
J
D
J
M
Manual
Bocelli
inria,
thanks
for
all
the
work
and
we're
looking
for
to
update
our
implementations,
we
had
an
impatient,
401
and
ro
to
you
for
this
bagging
tonight
and
one
thing
we'll
pay
particular
attention
to
is
you
know
how
complex
this
is
becoming
and
we
want
to
play
a
specific
role
in
this
working
group,
which
is
and
make
sure
that
even
for
single
binary,
the
simplest
case
of
smaller
size,
key
devices
class,
one
ordering
class
zero.
We
still
can
use
this
stuff.
I
mean
a
manifesto
and
yeah
I
think
it's
it's.
M
The
the
graph
is
become
becoming
three
complex
and
I'm,
just
wondering
how
how
this
is
gonna
fit
and
I'd
like
to
make
sure
that
in
the
graph
we
have
the
simplest
example
of
how
we
are.
We
probably
use
that
that
clear,
so
that
people
can
try
it
out
and
and
see
that
it
fits
or
even
on
the
small
stuff.
Yeah
I
can
already
think
of
maybe
some
things
we
might
consider
simplifying.
For
example,
the
several
ball
starts.
Maybe
there's
a
simple
way
to
go
about
it.
For
example,
yeah.
D
M
That
you,
if
we
have
a
way
to
point
to
where
the
Dermer
is
separate
from
the
manifest
we
might
have
a
way
to
point
to
where
the
text
is
separate
from
the
Menace,
which
might
you
know,
sometimes
it's
tough
for
them.
So
I'm
just
you
know
like
just
pretty
warning
about
this:
let's,
let's
make
sure
that
this
stuff
is
also
applicable
for
small
device,
because
we
want
this
to
be
also
true.
Can.
J
Let's
see
yes
emmanuel
this,
this
is
the
version
that
should
actually
meet
the
requirements
that
you've
brought
up.
So
if
we
go
forward,
let's
see
two
one
yeah
here
we
are
this.
This
is
the
encoding
that
we're
looking
at
and
it
should
cover
essentially
what
you
have
described.
I
recognized
that
the
the
multi-part,
the
severable
fields,
maybe
not
ideal
for
for
class
one
devices.
J
So
the
intent
there
in
the
draft
was
that
fields
could
be
made
severable
if
necessary,
and
I
specifically
call
out
that
it
costs
encoding
size
to
be
able
to
make
field
separable,
and
so
there
are
many
situations
where
that
would
not
be
desirable.
The
reason
I've
done
what
I
have
in
this
particular
example
was
I
wanted
to
show
the
pre
installation
information,
which
is
a
field
that
can
be
made.
J
Separable
is
kept
actually
in
the
manifest
so
that
no
additional
and
jumping
between
elements
in
the
blob
is
necessary,
but
at
the
same
time
the
installation
reference
is
is
present,
and
that
means
that
installation
information
is
external
to
the
the
smallest
part
of
the
manifest
I
think
that
when
it
comes
to
targeting
class
one
devices,
then
maybe
making
fewer
fields
severable.
In
this
way
it
would
be
at
least
part
of
the
right
answer.
F
This
is
I
think
it's
also
a
realization
of
like
last
time
and
the
meetings
before
we
talked
about
the
different
features
that
people
want.
But
of
course
all
these
features
come
with
a
certain
price
tag.
You
don't
have
to
use
them,
but
now
other
today
are
described
in
a
document
in,
for
example,
if
you
add,
if
you
use
firmware
encryption,
you
obviously
have
to
adapt,
add
extra
information.
So
in
this
case
it's
really
really
our
minimalistic
in
a
sense
of,
of
course,
that's
the
signature,
overhead
and
so
on.
F
D
N
So
what
I'm
gonna
cover
on
the
next
slide
is
a
little
bit
be
the
thinking
behind
that
eye
on
why
we
went
the
way
we
went
and
some
implementation
hi
on
the
server
side,
before
I
jump
into
the
high-level
structure
of
the
manifest
and
a
few
implementation
I
details
which
are
a
little
bit
different
than
than
others.
So,
let's
jump
right
into
the
next
slide.
The
key
thinking
for
us
was
that
a
what
a
manual
just
brought
up
a
very,
very
constrained
devices
I
want
to
keep
it
really
simple.
N
N
You
still
have
to
narrow
down
a
what
option
that
the
MCU
I
understands
and
can
handle
see.
You
typically
only
knows
about
one
signature
format
and
one
encryption
format,
and
so
on.
So
we
said,
I
will
keep
the
manifest
rather
platform-specific,
so
just
treat
this
huge
architecture
as
a
general
framework,
but
then
I,
some
of
the
fields
can
be
interpreted
by
the
specific
MCU
in
one
way
or
the
other,
and
therefore
you
don't
need
to
specify
like
pre-processing
or
installation
instructions.
N
It
becomes
much
easier
to
to
load
that
and
if
it's
straight
into
memory
and
execute
it
right
there
and
then-
and
maybe
even
keep
it
around.
If
you
want
to
do
at
a
station
doing
the
boot
loading
process,
you
could
keep
that
around
and
verify
the
signature
during
boot
as
well
all
right
on
the
next
slide.
N
N
So
that
way
on
the
next
slide
it
it
provides
for
a
very
condensed
format
and
we
think
think
that
a
simpler
format
can
also
be
I,
provide
less
vulnerabilities
because
it's
less
code
to
worry
about,
but
we
still
wanted
to
keep
it
a
still
quite
powerful.
Where
you
can
manage
multiple
images
from
different
authors,
which
can
be
signed
separately.
N
N
Let
me
so
the
the
manifest
format
itself.
I
was
not
planning
to
go
into
the
details,
but
it's
a
nested
structure,
just
like
the
others
I
you
have
one
big
container,
which
I
then
has
manifests
from
different
authors
in
again
for
that
very
simple
MCU,
though,
that
would
be
a
single
manifest
for
a
little
bit
more
complicated
MCU.
N
That
might
be
one
manifest
for
the
Wi-Fi
component,
one
for
the
co
core
OS
another
one,
maybe
for
the
application
I
each
one
of
those
I
can
have
multiple
can
have
multiple
images,
I
for
multiple
components
and
each
author
can
provide
its
own
signature
to
so
that
it
can
be
authenticated.
Coming
from
the
manufacturer,
for
example,
of
the
application
versus
the
the
Wi-Fi
firmware
and
then
the
up
date
server
would
sign
the
whole
manifest
set
I
with
its
own
signature,
all
right,
I
on
the
next
slide,
a
few
implementation.
N
That
installer
knows
how
to
install
it,
where
to
put
it
or
what
type
of
pre-processing
would
be
necessary
and
we
use
the
build
date
instead
of
a
separate
sequence
number,
and
that
way
we
keep
the
manifest
as
small
as
possible
so
that
we
can
target
even
very,
very
small
MC
use
all
right,
that's
kind
of
the
overview.
What
I
wanted
to
cover.
We
can
jump
into
any
of
the
details,
but
I
think
we
are
not
having.
We
don't
have
that
the
time
to
do
that
today.
F
F
F
Was
a
separate
aspect
of
the
presentation
which
is
we
talked
about
features
we
wanted
in
as
part
of
the
architecture
and
the
information
model,
work
and
Martin
in
his
presentation,
IV
that
he
doesn't
want
to
describe
some
of
those
fields
because
he
for
his
use
case,
he
doesn't
see
them
necessary
and
currently,
as
you've,
seen
with
friends
presentation
they
are
in
the
document,
but
you
don't
have
to
use
them.
So,
for
me,
a
question
is
even
if
we
decide
to
go
for
different
encoding
format,
serialization
formats.
F
What
is
the
expectation
from
the
on
what
functionality
you
need
to
describe
in
any
of
those
caersation
formats
from
the
information
model?
It's
it
you
do.
You
need
to
cover
everything.
What
do
you
need
to
cover?
Just,
for
example,
the
mandatory
fields
that
are
necessary,
ideally
I,
believe
there
should
be.
If
there
are
my
two
performance
in
Syria
station
for
months,
then
the
semantics
shouldn't
be
different
between
them,
which
would
otherwise
be
unfortunate.
I.
G
N
Answer
things
one
by
one,
Hannes,
I
I,
think
we
I
mean
the
way
I
look
at.
It
is
that
those
fields
are
not
explicitly
listed
in
the
in
the
format
I,
because
I
believe
that
an
MCU
can
have,
for
example,
a
simple
lookup
table
for
the
for
the
various
ones,
a
so,
for
example,
the
pre-install
conditions
I
can
be
implemented
by
the
Installer
rather
than
providing
them
in
the
in
the
in
the
manifest
or
I
mean
again.
This
is
a
when
you
look
at
the
the
implementation.
There
is
a
I.
N
F
N
From
Juan
Carlos
I
know,
I
don't
have
the
specifics.
I
can
provide
an
example,
probably
by
twice,
but
it
depends
a
little
bit
on
the
signature
format
and
so
on
different
signatures,
of
course,
of
different
sizes,
and
so
they
end
up
being
different
so
but
I
can
provide
on
the
mailing
list.
I
can
provide
maybe
a
typical
size
or
minimum
size.
D
J
J
N
J
Okay,
I
understand
that,
but
the
question
I'm
trying
to
drive
down
to
is
are:
are
you
specifically
referring
to
recasting
your
buffer
as
a
structure?
Yes,
okay,
that
is
undefined
behavior
by
the
C
standard
that
may
work
for
one
compiler.
It
may
work
at
one
time,
but
it's
not
guaranteed
to
work
between
versions
of
the
same
compiler,
I.
E
D
J
D
J
E
J
J
Well,
I
mean,
even
if
you
don't
have
a
schema
per
se,
you
still
have
to
have
a
schema.
The
schema
may
be
simply
in
code
and
I've
found
so
far
that
in
the
handling,
I've
done
of
manifests,
the
primary
consumer
of
resources
is
the
schema.
It's
how
I
validate
each
part
of
that
manifest,
regardless
of
extracting
it
from
an
encoding.
What
seems
to
be
more
significant
is
the
the
actual
handling
of
the
data
within
it.
It
all
does
have
to
be
validated.
D
A
So
is
actually
arm
so
I
think
this
conversation
just
goes
to
show
that
when
it
comes
to
the
details
of
processing
this
kind
of
stuff
in
C
in
boot,
loaders,
you
need
to
do
all
these
things,
regardless
of
how
this
eccentric
so
I.
Really
it's
kind
of
a
moot
point
on.
Oh,
you
don't
need
a
buffer
here.
You
don't
need
a
buffer
there.
You
don't
need
a
map.
This
you
have
to
do
all
those
things
I,
don't
really
think
it
makes
a
big
difference
either
way.
A
You
could
maybe
drop
that,
but
going
to
the
size
issues
so
I'm
guessing
motivation
here,
because
this
is
slightly
smaller
or
see
Bora
generic
encoding.
By
what
and
in
Brendan's
examples
were
like
30
bytes
larger
because
of
sea
bore.
Another
example:
was
a
hundred
bytes
larger
I
just
wanted
to
point
out
that
your
manifest
isn't
really
your
issue
here
when
it
comes
to
constraint,
networks,
we're
talking
about
100
bytes
savings
versus
a
hundred
thousand
by
firmware
and
that's
a
tenth
of
a
percent.
O
Rich
soils,
Akamai
I
just
want
to
point
out
they're
getting
a
signature.
Data
format
right
is
really
hard
and
really
tricky,
and
so
you
can
just
can
use
the
standard
signature
anyway
or
you
better.
Otherwise,
you'll
end
up
on
the
front
page
of
The
Times
and
therefore
the
savings
will
be
even
less
than
you
think.
P
Hello,
yeah
I
thought
not
yeah.
Sorry,
yeah
I
thought
it's.
A
motivation,
looks
like
a
suicide
right,
little
ones
of
size
right
size
that
a
good
question
too.
What's
the
rate
has
significant?
Yes,
but
other
side?
Are
you
making
a
part
of
the
coda
size?
It's
a
smaller
code
to
process
the
loading
memory
directly
Institute.
Well,
what
the
parser
code
and
others,
but
for
that
one
I
still
say:
what's
a
popularity
that
RT
device,
it
really
cannot
handle
this
see
ball,
could
sleep
or
the
parson.
F
This
is
nice,
so
this
is
again
a
tricky
question
of
you
need
a
pasta
in
any
case,
regardless
on
what
you,
where
you
store
it,
because
you
have
to
look
at
the
different
field.
She
crafted
instance
in
pepper
today.
F
One
of
the
arguments
that
we
had
initial
in
the
working
proven
we
propose
the
asn.1
format
was
we
want
to
use
ears
and
one
because
we
had
the
crypto
implementation
days
there
for
certificates
and
so
on.
So
we
needed
that
anyway,
then
others
came
along
and
said,
oh
well,
but
on
boy
you're
actually
going
to
have
that
pass
idea
as
well,
because
of
some
of
the
other
work
that
we
are
yeah.
So
in
essence,
it
turns
out
that
we
have
that
functionality
there.
F
For
other
reasons
already,
so
it's
kind
of
you
have
to
reformist
look
at
it
from
a
systems.
Point
of
view
like
what
are
the
other
components
you
have
on
your
systems?
Are
you
adding
any
extra
to
it
and
that's
that
of
course,
are
difficult
to
church
in
isolation
of
not
knowing,
but
how
exactly
the
system
isn't.
N
A
A
A
So
what
does
the
group
think
needs
to
be
done
across
all
of
these
platforms
and
will
one
format
do
it
or
do
we
need
specific,
College
specifics
choices
and
how
do
we
describe
them?
Those
are
the
questions,
I
think
that
are
before
us,
which
will
ultimately
lead
to
the
answer
to
the
question.
How
many
do
you
want
to
put
forward
in
RFC's.
Q
Exactly
oh,
so
the
first
thing
I
think
is
that
we
need
to
get
at
least
one
right,
so
that
that's
for
starters
and
then
and
then
I
would
really
like,
maybe
the
only
more
but
at
least
one
that
we
get
it
right
and
then
to
have
the
same
semantics
across
the
different.
If
there
is
something
else,
so
let's
focus
on
one:
do
it
right
and
then,
if
someone
wants
to,
you
know,
add
like
binary
stuff
or
other
things,
then
just
add
like
the
corresponding
mapping
to
the
base
the
base
line,
format
and
the
baseline
semantics.
Q
That
will
be
fine
and
if
I
go
back
to
the
example,
I
mean.
If
we
have
cdlt
to
define
like
this
your
schema,
then
you
know
if
you
need
to
redesign
the
whole
thing
for
a
binary
in
the
community
to
do
all
these
all
kind
of
complex
stuff.
If
you
try
to
solve
the
two
problems
in
the
same
time.
So
for
me
it
seems
pretty
simple
to
say:
okay,
lo
use
one
format,
one
scheme,
the
language
and
then
you
know
just
define
nothing's
define
our
stuff.
So.
A
K
Actually,
I
was
not
always
in
the
room,
so
has
Mathias
radish
comment
on
the
email
list
in
covered
here
already,
otherwise
I
will
bring
it
up,
so
he
brought
an
email
to
the
list
with
respect
to
discussion
in
the
room
and
said
I
didn't
get
the
discussion
totally
today.
Just
as
a
reminder,
the
suit
working
group
Charter
says
explicitly.
This
group
will
focus
on
defining
a
firmware,
update
solution
taking
into
a
core
past
learning
from
our
c4
108.
K
Thank
you
by
the
way
and
another
from
resolution
that
will
be
usable
on
class
one
constrained
devices
as
defined
in
RFC
7
to
18,
recursion
and
essence
devices
with
approximately
10
kilobytes
of
RAM
and
100
kilobytes
of
flash.
So
that
is
maybe
a
reason
why
you
have
subsets
and
an
optional
fields
and
manifests,
maybe
I'll
be
addressing
that,
but
we
should
address
that
explicitly
again.
F
This
is
not
a
sandwich
trying
to
respond
to
that
comment,
so
I
think
the
goals
haven't
changed,
makes
this
team
from
Brandon's
presentation
and
there's
the
options
which
you
don't
need
to
use.
If
you
have,
you
don't
need
a
feature
and
use
it
as
long
as
you
can
fit,
I
think
the
biggest
code
size
is
really
with
the
crypto
algorithms,
to
be
honest
in
and
and
DRAM
utilization
as
well
as
so
as
long
as
you
can
fit.
The
signatures
in
India
I
think
it
would
be,
will
be
fine.
F
F
D
They
fear
so
I
came
out
here
to
make
it
clear
I'm
talking
as
a
participant
in
the
press.
Exactly
mr.
chair
for
my
comment
here
so
I
think
part
of
a
question
that
I
see
people
talking
about
is
and
I
think
honest
gave.
A
great
summary
is
second
ago
how
getting
us
back
to
the
asn.1
discussion
and
so
on,
and
so
I'll.
Just
repeat
what
hunter
said.
D
They
would
like,
whichever
one
has
the
least
overhead,
so
that
gives
the
most
space
for
them
to
do
stuff
that
they're
actually
trying
to
do
right,
because
the
whole
update
process
is
kind
of
overhead
you're
designed
to
be
a
washer
or
a
motor
or
a
sensor
or
a
thermostat
or
whatever.
It
is,
and
so
the
more
that
you
can
devote
to
that,
the
better
that
you
can
do,
one
a
smaller
class
processor
and
save
costs
and
so
on.
D
D
If
he
already
had
C
bar
right,
we
could
already
have
that
parser
at
the
extra
code
is
minimal
compared
the
S
and
when
the
watch
the
code,
and
so,
if
you
think
about
a
microcontroller,
that
is
an
ecosystem
that
does
not
have
C
board
already
in
it
for
the
purposes
that
it's
doing
in
someone
an
ecosystem,
then
the
question
becomes
how
much
extra
code
and
how
much
extra
data
is
there
for
each
of
the
direct
manifest
formats
and
I.
Think
that
was
one
of
the
questions
to
a
Marten.
D
Is
you
actually
have
the
numbers
and
so
on?
Okay?
Now,
if
there's
an
argument
that
says,
if
I
already
have
C
for
our
parser
than
the
one,
that's
the
CBO,
our
parser
is
clearly
better
because
the
the
extra
overhead
is
close
to
zero,
because
I
already
have
that
right,
then
there's
a
relation
to
the
C
or
one.
If
there
are
processors
that
the
numbers
come
out
to
say,
there's
a
significant
difference
between
adding
a
Seaborg
version
for
code
and
data
is
much
larger
than
adding
the
binary
one.
D
Then
there's
a
reason
that
they
would
say
well,
the
binary
one
is
clearly
the
one
that
I
want
able.
Okay,
I
don't
know
without
knowing
the
numbers
but
I'm
saying
that's
what
I
see
as
the
core
question
here
is.
Do
we
want
one
of
em
I?
Don't
want
multiple
I'm,
not
worried
about
how
many
formats
the
server
has
to
intimate
the
server's
big
misterios
two
different
formats.
The
server
can
implement
both
of
them.
That's
not
a
problem.
Okay,
that's
why
we
have
the
information
while
blocking
in
the
first
place.
D
What
I'm
worried
about
is
making
sure
that
whatever
we
standardize
here
is
applicable
to
the
widest
set
of
IOT
devices
as
possible,
so
that
we
get
the
most
success
at
this
working
good
and
so
to
me,
weather
is
one
of
those
multiple.
It
really
comes
down
to
the
numbers.
If
the
case
is
there,
the
case
might
be
there
to
say
we
multiple
in
order
to
maximize
the
reach
of
our
working
group.
J
My
argument
a
few
minutes
ago,
was
that
the
schema
validation
is
actually
the
bigger
part
and
I'll
say
again
that
you
don't
get
rid
of
the
schema
validation
by
changing
the
format
you
just
have
to
do
it
anyway.
So
what
we're
talking
about
is
for
seaboard
on
a
device
that
doesn't
already
have
it
880
bytes
versus,
however
much
it
costs
to
implement
a
schema
validation
for
the
content
that
matches
the
information
model.
C
Person
from
icon,
yes,
is
Dave
Robin,
two
things,
maybe
maybe
conflicting.
We
have
business
lessons
learned
from
from
the
bacnet
committee,
which
of
course
was
born
in
the
80s.
We
love
shaving
bytes.
We
take
every
byte
on
the
wire
and
so
we're
we're
in
this
habit
of
trying
to
minimize
encoding
minimize
everything
thinking
about
using
binary
headers.
Instead
of
a
s
and
headers
things
like
that,
and
then
came
along
security
and
signatures,
and
it
just
blew
all
over
that
away.
So
I
mean
it
every
every
bikie.
C
If
you
save
ten
bytes
here,
it
pales
in
comparison
to
the
size
of
the
signature
you
put
to
save
load.
It
goes
along
with.
So
that's
just
one
point
so
I.
The
point
of
that
would
be
that
I
would
favor
flexibility
and
extensibility
in
the
formatting,
not
absolute,
fixed
formatting,
because
you
always
it's
easy
to
parse,
but
you
will
read
it
as
soon
as
you
want
to
add
one
more
information,
so
a
TLB
or
a
tag
or
some
sort
of
structure.
C
That
indicates
what
the
fields
are,
so
you
can
sneak
another
one
in
is
is
a
better
approach
than
an
absolutely
fixed
format.
So
I
think
that
that
might
that's
one
point.
My
other
point
is
we
keep
talking
about.
Oh
well,
the
Seaboard
of
a
seam
or
library
is
available,
or
the
ASN
libraries
available
as
much
as
I
love
seaboard,
it's
available
in
my
application,
using
its
memory
allocations
and
all
of
it
once
it
is
established
and
running.
It
is
not
available
in
the
bootloader.
C
If
it
is
available,
it's
because
I
copied
and
pasted
and
adapted
it
to
the
bootloaders
environment.
It's
not
really
available,
as
is
so.
Let's
not
make
assumptions
that
just
because
your
application
is
doing
something
that
your
bootloader
can
also
do
it.
We
recently
ran
into
this
in
the
back
net,
where
we
were
trying
to
reuse
some
high-level
application,
read
property,
a
send
coded
stuff
to
get
our
credentials,
and
we
realized
that
we're
trying
to
do
this
from
the
data
link
layer.
C
The
data
link
layer
does
not
want
to
call
up
into
the
application
layer
in
order
to
get
this
service,
and
so
we
actually
changed.
It
made
it
native
to
the
data
link
used
for
encoding
format,
so
that
all
that's
saying
is
the
bootloader
is
a
perhaps
a
different
environment
than
your
application
run
in
the
environment.
That,
let's
not
forget
that.
R
If
a
code
path,
if
you
end
up
creating
a
code
path
that
is
lightly
used,
I'm
concerned
that
it
won't
get
the
exercise,
you
needed
to
make
sure
that
it
actually
is
secure,
and
it
remains
so
I
think
from
this
group
if
it
has
to
go
with
two
formats.
I
think
that's
understandable,
I!
Think
if
you
end
up
with
more
than
two
formats,
that's
problematic.
A
Zack
Shelby
I
wanted
to
go
back
to
Alex's
earlier
comment
about
encoding
x',
and
I
really
do
believe
that
in
coatings
are,
are
something
you
do
on
an
information
model.
That's
shared
between
the
encoding
I
mean
at
the
ITF,
giving
a
long
history
of
doing
that
sometimes
well,
but
I
would
not
want
to
see
two
different
encodings
based
on
two
different
information
models.
That
would
be.
A
Being
proposed
right
now,
so
that
is
out
so
if
we
did
want
to
do
at
Martin's
proposing
it
would
need
to
be
on
exactly
the
same
in
promotion,
exactly
the
same
structure
on
your
just
encoding,
the
Alliance
different.
My
understanding
is
that
both
of
the
proposals
believe
they
implement
the
same
information
on
now
as
a
working
group.
You
need
to
validate
that,
but
that
was
the
intent
of
the
officer,
so
I
do
believe
that
you'd
have
to
redo,
what's
done
here
in
a
pretty
different
way,
in
order
to
actually
standardize
this,
if
you
did
now.
A
The
other
thing
I
wanted
to
comment
on
is
that
we
shouldn't
consider
these
microcontrollers
as
completely
proprietary.
Things
used
to
be
that
everyone
handcrafted
their
real-time
kernel
with
their
bootloader
and
they
did
some
magic
stuff
on
their
microcontroller,
because
their
magic,
guy's
embedded
developers
believe
that
they're
magical
that's
going
away.
We
do
have
platform
operating
systems,
we're
really
trying
to
do
open
source
communities,
we're
sharing
bootloader
technology
across
hundreds
and
hundreds
of
different
microcontroller
targets.
We
need
to
be
able
to
reuse
this
in
standard
way.
A
We're
sharing
the
libraries,
even
though
it
might
not
be
in
the
same
bootloader
those
libraries
aren't
in
the
same
ecosystem
of
open-source
components
very
well
tested,
which
is
a
good
thing,
and
we
share
that
same
library
between
the
application.
The
more
we
can
do
that
better
search
want
to
point
out
that
things
are
changing
for
embedded.
This
is
not
the
old
world
of
everything's
proprietary
on
Carlos,
then
Brendan,
yep
or
Carlos
leniency.
Folks,
you.
G
Just
want
to
do
+1
on
Dave
and
eight
points
and
and
trying
to
answer
the
question
whether
we
need
one
or
many
I
think
it's
really
coming
down
to
requirements.
We
need
efficiency,
because
we
need
to
make
sure
that
we
address
all
these
different
use
cases
and
we
need
flexibility
and
extensibility
to
make
sure
that
we
are
forward-looking.
So
I
think
just
want
to
make
sure
that
we
keep
those
in
mind
when
we
want
to
address
the
question
and
they'll
Elliott
also
brought
a
good
point.
So
I
think
the
number
two
ish
is.
J
I
just
want
to
ask
the
question:
are
we
planning
to
be
standardizing
a
secure
boot
header
format,
I
thought
we
were
doing
update
but
I'm
hearing
a
lot
of
discussion
about
about
boot,
loaders
and
so
I
think
we
need
to
answer
that
question.
Is
this
about
doing
update
or
is
this
about
doing,
secure
boot?
Because
if
we're
talking
about
what
goes
in
the
boot
loader
and
what
doesn't
then
we
have
strayed
into
secure
boot
and
we're
not
doing
firmware
update
anymore.
P
Had
the
most
software
so
really
have
a
trouble
to
find
equip
the
lab
race,
so
firmware
can
be
encrypted
and
it
can
be
signed
so
now
update
you
need
to
decrypt.
You
have
a
code
to
decrypt
as
this
large
code
and
also
we're
about
signature
work
on
integrating
data
code.
Science
is
much
more
significant,
larger
than
just
a
part
in
some
data
right
where
the
binary
is
called
C
boy.
It's
already
concise
a
lot
by
a
word.
Concise
already
may
be
smart
enough
right,
I
just
say
the
benefit
of
using
multiple
formats.
P
What's
already
already
challenging
a
crypto
library,
there
may
be
a
different
format.
Do
not
have
that.
Compare
their
benefits.
One
oh
wow,
but
I'd
say
if
there's
a
case
where
you
don't
need
to
formally
encryption
for
those
cases
where
final
format
does
save
some,
maybe,
but
that
are
actually
here.
So
will
that
use
case?
It's
a
public.
I
Person,
that's
moving
to
data
points
facility,
the
number
that
was
thrown
in
the
about
800,
something
bytes
for
SIBO
decoder.
That's
a
generic
decoder.
That
includes
floating
point.
So,
if
you
take
our
coding
point,
it's
720,
and
maybe
you
can
share
such
little
bit
more
so
I.
Don't
think
that
that's
really
something
we
need
to
argue,
but
I
think
the
more
interesting
question
is
whose
signatures
do
we
actually
validate
here?
So
if
we
convert
between
forwards
somewhere,
that
means
that
the
the
old
signature
that
was
on
the
old
format
yeah.
I
Essentially,
you
can
only
verify
that
if
you
actually
still
have
the
old
format
around
so
depending
on
on
what
is
actually
the
authorization
structure
of
the
hood
louder,
it
may
be
no
cost
at
all
to
have
a
completely
different
format,
because
you
resign
this
stuff
anyway,
and
and
then
you
can
of
course
do
it
in
a
different
format.
All
it
may
be
very
integrative.
The
bootloader
actually
tries
to
be
part
of
an
authorization
chain
that
includes
the
original
signature.
Then
it's
hard
to
use
that
if
you
are
not
using
the
same
pump
so.
A
I
Just
wanted
to
put
in
two
data
points
here
so
generally
I
think
that
it
it's
not
hard
to
do
that
part
of
SIBO
that
they
actually
need
in
a
bootloader.
So
I
don't
buy
the
argument.
We
have
to
do
something
simple.
It
would
not
about
I
wanted
to
find
out
that
there
are
two
very
different
situations
where
one
where
you
resign
by
a
different
authority
and
one
way
you
are
trying
to
use
the
original
authority
and
those
have
different
influences
on
what
we
actually
came
to.
Thank
you.
C
Okay,
Dave
found
a
problem
following
up
on
what
Zach
said
and
Carson
just
clarified
what
I'm
saying
I'm,
actually
the
the
what
I've
heard
in
the
past
you
say:
well,
we
already
have
Seaborn
there.
The
reason
was
that
he
was
a
code
size
in
the
device
and
you
know
therefore
the
library's
lying
there.
Those
are
800
bytes
or
whatever
already
there.
Let's
use
them.
That's
not
actually
my
point
I
think
if
you
wanted
I,
don't
think
that's
a
valid
argument
is
what
I'm
saying,
but
there
is
a
strong,
valid
argument
to
be
made
sorry.
C
This
is
very
loud
like
to
reuse
things
that
we
know
and
code
that
is
debugged,
and
so,
when
I
said
cut
and
paste
see
more
into
your
bootloader
and
adapt
it
to
its
memory
structure.
I
meant
it
literally.
That's
great!
That's
not
a
bad
I'm,
not
saying
that's
a
bad
thing.
You've
got
this
library
that
works.
You
might
need
to
use
in
another
environment.
So
my
point
was:
don't
make
the
argument
that
it's
lying
in
memory
and
I
can
reuse
it
exactly
where
it
is,
but
the
technique
and
the
encoding
and
the
code
that's
debugged.
C
I
think
might
be
a
good
thing
and
now
so
the
second
point
about
clarifying:
why
don't
we
start
talking
about
boot?
Loaders,
all
of
a
sudden,
I
think
you
know,
because
we're
running
we're
getting
my
act
across
my
application
across
the
wire.
That's
not
the
bootloader
doing
that,
but
eventually
you've
got
to
hand
it
to
somebody
to
apply
the
patch
and
that
to
me.
That's
where
my
system
reboots,
that's,
not
really
the
bootloader,
but
we
call
it
boot.
This
is
the
thing
that
applies
to
patch
checks,
the
signatures
and
then
restarts
the
application.
J
The
the
point
I
was
making
when
I
said
that
was
perhaps
I
was
a
bit
obtuse
and
the
what
I'm
trying
to
get
to
is
that
there
are
lots
of
existing
formats
for
boot,
loaders
to
verify
the
integrity
of
the
firmware,
their
booting
and
I'm.
Not
so
naive
as
to
think
that
absolutely
everyone
is
going
to
jump
on
this
format
as
the
mechanism
that
they
use
to
verify
an
image
before
it's
booted
I.
J
In
fact,
I
would
argue
that
when
it
comes
to
separation
of
authority,
it
would
be
highly
probable
that
the
authority
for
delivering
an
update
is
not
the
same
as
the
authority
for
signing
a
firmware,
and
we
shouldn't
conflate
the
two.
That's
not
to
say
that
you
can't
use
the
header
that
we're
describing
as
a
boot
time
header
just
that
I
think
it
might
ignore
some
other
system
constraints.
I.
A
M
Daniel,
fidelity
in
RIA,
I
think
back
to
the
question
of
how
many
formats
you
should
move
forward.
I
think
we
all
know
the
answer
to
that
the
minimum
number.
So
we
already
know
that
the
minimum
is
greater
than
one
and
I
think
the
question
is
is:
should
we
go
up
to
two?
Is
the
decision
factor
is
applicability
to
class
one
devices
or
order
line
path
you
take
if
we
need
two
formats
you
know
so
that
exists.
One
of
them
is
going
to
be
widely
used
on
Catalan
devices
and
well.
You
know,
let's
go
with
two.
A
P
A
M
P
R
A
G
A
M
C
A
D
D
A
D
No
I
think
you
just
summarize
where
our
next
steps
are
I.
Don't
have
anything
else
to
add
I.
Think
there's
some
that
the
next
steps
that
we
know
of
just
as
a
reminder
did
the
authors
have
things
Brendan
and
Hamish
talked
about.
They
need
to
update
the
information
model
and
architecture
documents,
and
once
we
see
those,
then
we
can
decide
whether
we
have
consensus
on
those
and
what
our
next
step
is
there.
But
we
need
to
see
the
text
first.