►
From YouTube: IETF102-SUIT-20180718-0930
Description
SUIT meeting session at IETF102
2018/07/18 0930
https://datatracker.ietf.org/meeting/102/proceedings/
B
C
A
A
A
A
Alright,
so
before
we
move
on
with
the
agenda
to
give
a
really
brief
status
report,
so
so
we've
adopted
the
architecture
and
information
model
drafts.
Thank
you
to
the
to
the
authors
for
all
their
work.
On
on
that
On
June
6th,
we
held
a
virtual
interim
where
we
focused
predominantly
on
the
architecture
and
and
manifest
drafts.
We
generated
a
lot
of
comments
out
of
that
and
work
is
progressing
on.
Those
drafts
on
the
minutes
have
been
posted.
A
A
A
We
still
have
the
serialization
format
to
to
adopt
we're-
probably
not
going
to
get
to
that
today,
but
we
will
likely
have
a
virtual
interim
in
in
in
between
this
and
and
and
the
next
one.
The
next
IETF
meeting
so
I
think
a
focus
of
that
might
be
to
to
work
on
on
adopting
a
manifest
serialization
format.
A
We
we
have
a
milestone
to
submit
an
information
model
to
the
iesg,
so
we'd
like
to
really
focus
our
efforts
on
on
that,
as
well
as
a
missing
milestone,
which
I
think
we
need
to
add
which
is
submit
the
architecture
document
to
the
is
G.
So
yes,
exactly
so,
if
it's
okay
with
the
working
group,
we
would
like
to
submit
both
the
architecture
and
and
manifest
information
model
to
the
to
the
is
G.
A
A
D
There
are
multiple
ins
use
here,
so
that's
that's
nice,
a
hard
worker,
the
module
with
ECDSA
support,
miss
curve
and
and
so
on,
and
so
on
also
the
possibility
to
connect
to
other
ports
if
you
want
to
have
an
off
chip
in
our
F
off
port
microcontroller.
So
a
couple
of
different
use
case
that
we
are
going
to
talk
about
later
on
in
in
one
port.
So
that's
I
think
quite
useful
and
that's
what
we
have
been
playing
around
with
that
at
the
hackathon
itself.
D
So
I
think
that
amy
has
been
great
in
supporting
the
newcomers
and
he
produced
an
excellent
write-up
and
you
can.
You
can
see
the
link
later
on
so
I
think
it's
even
even
if
you
are
relatively
new
to
the
suit
work.
I
think
that's
something
one
and
a
half
days
well-spent
where
you
actually
take
away
a
lot
of
info
in
and
and
the
board
this
world,
so
we
can
play
around
with
it
later
on
so
join
us.
This
is
what
we
produced.
D
What
was
learned
so
actually
we
I
believe
we
learned
a
couple
of
things.
One
is
probably
we
need
to
do
a
little
bit
more
homework
before
going
into
this
hackathon
next
time
in
having
everything
the
whole
development
environment
set
up
already
ahead
of
time,
so
we
don't
spend
half
a
day
more
or
less
to
just
install
stuff,
so
that
would
obviously
be
useful.
So
we
will
take
that
into
account.
D
The
new
hardware
was
required.
Some
learning
curve
on
the
coding
site
I
think
we're
not
quite
there
for
a
reference
implementation.
In
my
opinion,
so
we
have
the
from
the
last
London
hackathon
to
this
one.
We
now
have
a
cosy
implementation,
which
is
awesome
produced
by
the
India
guys,
unfortunately,
at
some
licensing
issue
for
some
of
them,
so
we
are
going
to
release
another
cosy
implementation
with
a
different
license
any
day
now.
So
hopefully
that
will
satisfy
their
needs
for
some
of
you,
but
also
the
SIBO
implementation.
D
There's
a
lot
of
stuff
there
that
can
be
sort
of
stripped
down
and
maybe
there's
a
possibility
just
for
a
very
constrained
SIBO
implementation
only
for
these
boot
loaders,
so
we'll
have
to
look
into
that
the
spec
itself.
As
soon
as
you
all
know,
from
the
discussions
on
the
list,
there
have
been
lots
of
changes
and
we
get
to
that
and
that
obviously
made
it
more
difficult
to
work
during
the
during
the
meeting.
The
API
of
the
tiny
Co
implementation
is
also
everything
but
intuitive.
D
So
there's
and
there's
some
some
pain
there
that
you
need
to
go
through
just
to
give
you
a
flavor
of
it.
So
you
you
traverse
the
different
objects
in
this
in
this
C
board
structure
and
this
manifest
and
you
read
something
you
advance
it.
You
need
to
say:
oh,
go
Chum
to
the
next
object
and
it's
okay,
that's
fine!
D
But
then
there's
some
read
operations
that
automatically
advance.
So
you
you
have
this
sort
of
like
somewhat
inconsistent
behavior.
So
sometimes
you
have
to
advance
to
the
next
item
manually
to
the
next
element
and
sometimes
not
a
little
annoying
and
there's
no
ease
or
no
obvious,
and
not
so
obvious
on
how
you
would
traverse
some
of
the
data
structures
in
the
end,
that
was
good.
D
D
What's
next
I
believe
what
what
we
could
and
that's
not
just
my
my
thinking
what
we
could
do
is,
as
we
advance
in
the
manifest
format,
we'll
have
to
keep
up
with
the
code
as
well
I.
So
that
would
be
something
to
do
already,
maybe
ahead
of
time
before
them
before
they
win.
Also
the
cozy
libraries
which
I
mentioned
earlier
and
then
finally
going
into
some
of
the
more
advanced
use
cases.
Since
we
now
have
the
bought
encryption.
D
Russ
has
this
post
Kwantung
based
thing?
Maybe
that's
something
to
look
into
so
there's.
Definitely,
if
also
for
students
who
want
to
do
some
projects,
I
think
there's,
there's
something
there
for
them
to
look
into
also
performance,
energy
power,
consumption,
etc,
etc,
and,
and
have
you
some
of
you
involved,
please
join
us
and
talk
to
me
and
figuring
out
how
how
to
be
actively
and
what
how
you
could
contribute.
D
D
E
D
Okay
architecture
document,
so
there
were
as
they've
bottom
I
I
said
that
we
had
the
virtual
interim
meeting
and
for
that
one
we
submitted
the
in
preparation
of
that.
We
submitted
a
serial
version
which
we
discussed
BEC
them
so
I'm
not
going
to
focus
on
those
changes
again,
but
there
have
been
a
lot
of
changes
on
the
document
that
also
in
the
0-1.
D
So
we
tried
to
come
up
with
new
terminology
and
I'm
going
to
talk
about
that,
and
hopefully
we
can
settle
on
this,
because
that
obviously
led
to
lots
of
changes
in
the
text
and
there
was
a
desire
to
sort
of
change.
The
description
for
operating
modes
and
I
will
talk
about
that
briefly
as
well.
I
hope,
that's
also
a
satisfactory
direction.
We
had
a
few
examples
provided
by
David
Brown
and
which
I
incorporated.
He
also
became
a
co-author
for
his
text.
D
Contributions
in
a
lots
of
editorial
changes,
the
entities
that
we
have
now
there
they're
also
in
the
device.
So
that
also
is
the
entity
that
trades
the
firmware
and,
in
the
manifest,
explicitly
point
out
that
they
are
multiple
also
potentially,
because
we
have
on
a
single
device
there
may
be,
as
mentioned
before.
There
may
be
multiple
microcontrollers.
They
even
within
one,
a
single
microcontrollers.
You
may
get
software
from
different
sources,
so
I'm
trying
to
highlight
this
fact.
D
So
then,
and
that's
a
terminology
we
sort
of
like
took
a
lot
bit
over
from
the
itu-t
if
they
allure
suggested
that
a
little
while
ago
and
have
been
trying
to
find
a
way
to
best
incorporate
this.
So
this
communicator
is
a
component
of
the
device
that
acts
with
interacts
with
the
firmware
update
server.
It
basically
receives
the
firmware
images
and
triggers
then
the
reboot,
the
update
of
those
and
start
up
the
new
image
it.
D
There
are
different
ways
it
can
interact,
it
can
borrow
it
can
get
a
notification
and
sort
of
more
a
push
versus
pull
mode
and
there's
also
some
text
in
there
that
talks
about
that.
You
know
in
a
practical
deployment,
it
may
actually
be
a
little
bit
more
complicated
because
there
may
be
multiple
images
that
you
need
to
download
because
there's
some
dependencies
and
so
on.
It's
on
so
to
take
care
of
those
cases
as
well,
not
just
focusing
on
the
most
simplistic
one,
there's
a
status
tracker,
which
is
a
little
bit
out.
D
It's
part
of
the
architecture
but
outside
of
what
we
are
currently
standardizing.
So
this
is
a
sort
of
a
device
management
functionality,
our
component
that
keeps
track
of
the
firmware
update
process,
and
it
knows
what
firmware
is
installed
on
a
device
and
what
sort
of
state
in
the
update
the
device
goes
through.
D
It's
a
common
component
people
deploy
in
these
systems,
and
so
it
allows
fine
grained
monitoring
of
changes
in
the
whole
fleet
of
devices
that
a
device
or
a
device
operator
would
use
and
I
will
show
a
figure
later
on
on
how
these
different
boxes
fit
together.
The
firmware
update
server
as
quite
uncertain
blight.
Surprisingly,
it
stores
the
firmware
images
and
the
manifest
and-
and
it
may
be,
multiple
of
them
admit
along
a
chain
of
sort
of
communication
paths.
D
The
they
are
in
this
device
network
operator.
That's
a
new
terminology
that
we
added
the
device
operator
is
sort
of
responsible
for
the
day-to-day
operation
of
the
IOT
devices
versus
the
network
operator.
Who
is
really
about
operating
the
network
where
the
IOT
devices
are
connected
and
we
introduced
those
because
we
were
in
discussions
at
the
inter
meeting
and
Nas
at
the
lan,
an
IDF
meeting.
D
We
were
talking
about
the
cases
of
what
is
the
level
of
influence
and
an
authorization
or
the
mission
decisions
that
those
entities
take
when
deploying
a
firmware
update
solution,
and
that's
also
documented
in
some
of
the
threats
and
use
cases.
So
so
I
was
necessary
to
introduce
those
Frank
from
Nordic
semiconductor
suggested
also
to
add
another
entity.
He
called
it
the
OEM
operator
well,
as
the
name
indicates
his
sort
of
the
entity
that
builds
a
specific
component,
so
you
will
I
haven't
so
he.
This
was
a
little
bit
buried.
D
The
human
rights
our
review,
so
it's
a
little
bit
less
visible,
but
but
if
I
I
think
it's
worthwhile
to
brainstorm
a
little
bit
about
whether
we
need
to
have
the
terminology
for
the
OEM
in
this
whole
picture
as
well
to
to
distinguish
between
the
guy.
Who
is
running
these
our
maintaining
these
devices
and
someone
who
actually
builds
the
different
components
not
yet
in
the
document.
D
Obviously,
so
if
you
have
some
perspective
on
this,
let
me
know,
and
then-
and
that
was
really
the
difficult
part
is
how
do
we
actually
separate
the
communication
architecture
from
the
whole
key
infrastructure
and
authorization
infrastructure?
And
then
they
I
introduced.
What
I
call
it
couldn't
come
up
with
a
better
name,
trust
provisioning
authority
and
what
it
does
is
it
distributes
trust
anchors,
as
well
as
authorization
permissions
to
the
different
entities?
D
There's
some
sort
of
orthogonal
infrastructure
that
has
to
exist
that,
besides
the
communication,
infrastructure
and
I'm
trying
not
with
a
figure
but
mostly
with
text
explaining
that
there's
something
going
on
here
that
there's
permissions
distributed.
And
maybe
there
are
some
examples
that
we
would
have
to
provide
in
there
to
make
this
more
obvious.
G
F
Think
this
this
the
cover-up
sites,
the
last
couple
of
slides
you
have
presented
kind
of
indicates
that
that
there
are
two
different
problems
that
need
to
be
solved.
One
is
the
manifest
that
we
have
been
talking
about
here,
but
there's
also
a
need,
at
least
in
many
situations,
to
actually
describe
the
the
set
of
players
and
and
what
specific
authorization
function
they
have
in
the
overall
flow,
and
that's
maybe
a
good
follow-on
thing.
F
We
could
do
in
this
way
before
a
different
working
group,
so
a
device
that
has
a
certain
role
in
in
such
a
flow
in
such
a
sequence
of
operations
can
find
out
when
it
has
to
do
what.
So
we
have
a
sequence
of
processors
in
the
manifest
right
now,
but
that's
a
bit
weird
because
it
comes
from
the
original
source,
so
yeah,
maybe.
D
D
Yeah
well,
this
is
this
text
was
added
and
this
entity
more
in
response
to
discussions
we
had
earlier
because
we
were
trying
to
say
okay,
the
author
of
the
firmware.
It
adds
the
manifest
and
obviously
it
as
signs
it
and
and
somehow
the
key
that
it's
used
for
signing.
It
needs
to
be
verifiable
by
the
device,
but
then
we
add
it
on
the
possibility
that
the
network
operator
also
signs
for
some
other
party
signs.
And
how
do
you
make
take
care
of
this
that
they
they
don't
create
any
new
firmware?
D
D
To
provide
I
expect
in
most
cases,
I'm
sort
of
this.
The
story
is
fairly
or
the
processing
steps
and
the
trusts
aren't
changes
fairly
simple,
but
of
course
there
may
be
some
more
elaborate
cases,
so
maybe
documenting
them
and
then
figuring
out
what
to
do
afterwards.
Is
it's
a
good
idea
so
Erik.
H
Monk,
have
you
guys
actually
thought
about
what
are
the
different
use
cases
for
this,
because
I
think
that
in
the
past,
there's
been
other
ones
that
have
come
up
like
what
happens
if
the
manufacturer
went
out
of
business
and
you
know
hard,
can
you
actually
sort
of
insert
things
in
here?
So
there's
that
aspect?
It's
also
that
if
I
can
break
into
this
part
of
the
system,
I
can
give
any
device
any
trust
anchor
I
want
to
so
it
it
operates
at
a
different
level
from
a
security
threat
perspective
right.
H
D
There
are
various
use
cases
described
in
in
both
more
so
in
the
information
model
document
that
deal
with
sort
of
threats
of
our
problems
that
relate
from
the
different
trust
chains
web.
So,
let's
say
more
focused
on
the
operational
side,
rather
than
the
worst
case,
where
companies
go
out
of
business
and
which,
in
general,
is
that
sort
of
a
little
bit
of
that
case.
H
Okay,
so
maybe
the
dependent
there,
because
because
one
way
of
architecting,
the
system
is
saying
that
okay,
a
device
will
have
one
or
more
trust
anchors
they.
They
might
be
a
separate
process
of
being
able
to
update
those
funds
right,
adding
removing
whatever,
but
that
could
be
separated
out
from
the
core.
Okay,
this
our
drive,
the
software
updates
and
then
have
a
support
one
under
different
security
concerns
about
what
does
it
mean
to
reassign
a
device
and
give
it
new
trust
anchors
through
its
life
cycle,
go
ahead,
Brendon.
I
Was
essentially
that
it
was
going
to
be
a
mechanism
that
allows
a
user
of
a
device
to
puts
some
kind
of
trust
anchor
onto
the
device.
The
trust
provisioning
authority
was
intended
to
be
the
entity
that
we
usually
refer
to
as
the
OEM.
The
problem
that
we
run
into
is
that
om
ends
up
meaning
a
lot
of
different
things
to
a
lot
of
different
people,
and
so
by
putting
this
this
extra
layer
in
this
trust
provisioning
authority.
I
In
that
situation,
that
white
label
vendor
isn't
going
to
want
to
have
to
assign
trust
to
different
different
users
for
different
devices.
So
in
that
model
the
trust,
provisioning,
Authority
concept,
starts
to
make
more
sense.
What
it
allows
the
the
OEM
to
do
is
it
allows
them
to
provide
a
channel,
and
that
channel
is
what's
used
by
the
by
the
customers
of
the
OEM
to
put
their
own
trust
anchors
on
to
the
device,
thus
and
then
make
the
device
no
longer
claimable,
if
you
will
with
those
trust
anchors.
H
H
You
know
reacquired,
because
someone
bought
the
building
that
it's
in
whatever
right,
I
think
they're
very
different
concerns
about
the
initial
I
need
to
complete
manufacturing
on
the
device
which
you
actually
need
to
do
as
far
as
I
can
tell
in
a
in
a
Faraday
cage,
whatever
right,
where
nothing
else
can
come
in
and
interfere
with
it,
because
you
have
no
security
to
build
anything
on
it.
Anyhow,
because
you
have
no
root
of
trust
already
installed,
I
mean.
I
There
are
kinnison
surround
that
this
is
this,
isn't
about
ensuring
the
that
this
isn't
a
whole
solution
right?
This
is
talking
about.
A
channel
is
talking
about
a
framework
than
what
you
do.
This
a
device
has
to
make
decisions,
do
I
trust
the
person
who's,
trying
to
give
me
a
new
trust
anchor
and
how
do
I
trust
the
person
who's
trying
to
give
me
a
new
trust,
anchor
and
I'm,
not
saying
that
this
is
something
that
has
to
happen
in
the
Faraday
cage.
There
can
be
keys.
I
Of
managing,
it
is
to
put
say,
print
a
pre-shared
key
on
the
outside
of
a
device,
an
H
Mac.
The
thing
you
send
to
it
then
does
its
match
that
yes,
then
the
person
must
be
in
physical
possession
of
the
device
right.
So
there
are,
there
are
mechanisms
that
you
can
install
to
deal
with
that.
The
point
here
is
that
there
needs
to
be
a
mechanism
in
place
on
devices
by
which
trust
anchors
are
installed.
I.
H
Actually,
disagree
because
I
think
suit
can
be
perfectly
successful.
By
saying
we
assume
that
there
is
a
manufacturing
process,
whether
happens
in
one
place
or
in
two
places
where
some
basic
software
and
a
trust
anchor
is
installed
and
now
I
can
go
and
update
software
on
this
device
from
by
someone
who
is
actually
trusted
by
that
original
trust.
Anchor
right.
Someone
is
part
of
the
original
thing,
and
now
you
can
offer
update.
You
cannot
do
ownership
transfer,
but
that's
a
different
problem,
so
don't
cancel.
I
Them
that's
my
heritable
sorryi
one
more
thing,
I'll
say
on
that,
and
it
was
not
intended
to
conflate
those
two
ideas.
The
the
point
of
this
is
that
there
are
two
roles
here:
there's
one
role
with
it's:
the
person
who
writes
the
software
for
the
device
and
there's
another
role.
That's
the
person
who
puts
the
authority
for
writing
software
onto
the
device
and
there's
in
no
way
is
intended
to
say
that
those
can't
be
the
same
people.
This
absolutely
can
be
part
of
the
same
workflow.
I
J
J
D
Actually
thought
about
that,
but
the
issue
here
and
and
I
is
that
it's
not
just
about
trust
anchors.
It's
also
about
permissions.
So
one
of
the
things
that
we
talked
about
was
there
are
different
elements
in
the
manifest
and
we
are.
There
is
a
possibility
to
allow
others
to
override
some
of
those
elements.
D
Some
of
those
elements,
for
example,
we
had
the
use
case
where
the
network
operator
wants
to
override
the
place
where
the
ffermwyr
should
be
retrieved
from
by
the
device,
and
so,
if
that
network
operators
giving
the
permission
to
do
that
override
on
that
specific
field,
then
this
has
to
be
communicated
somehow,
rather
than
overriding
other
fields,
and
so
I
felt
that
using
a
trust,
anchor
terminology
for
also
for
this
functionality
seemed
a
little
bit
dumb.
A
long
shot.
I
don't
know.
F
D
I
try
to
do
that,
but
I
will
double-check:
okay,.
D
Getting
to
the
operating
modes,
so
we
now
have
these
three
modes
that
I
think
they
Taylor
proposed,
which
is
a
client
initiated
server
initiated
and
a
hybrid
update.
The
in.
In
short,
the
client
initiated
uses
the
communicator
to
talk
to
the
film
updates,
to
figure
out
whether
it
is
a
new
firmware
on
and
be
done
with
it.
The
serve
initiated
is
one
where
you
can't
just
reverse
the
roles,
because
in
a
typical
deployment
you
have
some
nuts
and
fire
or
sitting
around.
D
So
it's
actually
the
status
tracker,
who
knows
and,
as
the
name
says,
keeps
track
of
the
status
of
the
device
knows
what
firmware
versions
are
running
on
it.
Individual
devices
knows
actually
what
devices
out
and
they
feel
in
the
first
place
and
knows
how
to
communicate
to
those
potentially
because
there's
a
long
lived
connection
with
that
status
tracker
and
then,
when
it,
when
that
status,
tracker
figures
out
that
it
has
to
do
an
update.
It
basically
sends
in
tracks,
with
the
firmware
update
server,
to
provide
that
update
to
their
client.
D
K
If
they
were
I
remember
at
the
inter
meeting
there
was
a
comment
on
the
terminology:
I
think
there
was
some
confusion
around
the
term
modes
which
implied
to
some
people
that
a
device
had
to
be
capable
of
multiple
of
them,
and
so
that's
not
the
case
here.
This
is
you
can
pick
and
choose
or
whatever
so
maybe
operating
models
or
something
like
that.
Okay,
I
think
I
can
change
so
in.
D
So
here's,
if
you
listen
to
my
description
of
the
determinants
of
the
terms,
you've
status,
strike
sort
of
talks.
The
device
keeps
track
of
what's
going
on,
to
communicate
on
the
device
talks
to
the
firmware
updates
server,
one
or
multiple
authors
on
providing
firmware
images
to
the
server,
and
there
may
be
multiple
servers
and
maybe
even
a
sequence
depending
on,
for
example,
if
you
get
it
from
a
server
store
it
on
a
smartphone
or
tablet
and
then
push
it
on
on
a
device
using
UART
or
really
or
whatever.
D
So,
based
on
on
the
feedback
from
from
David,
we
added
a
few
examples
and
I
think
they're.
Quite
a
quite
nicely
illustrate
what
we
had
discussed
on
actually
on
the
manifest
document
itself,
but
just
in
a
in
a
use
case.
Example.
He
also
provided
links
to
existing
hardware.
That
does
this,
of
course,
I
admitted
the
links,
but
you
can
look
it
up
if
you,
if
you
want
to
even
get
more
details.
So
this
is
the
first
one
is
very
briefly
walk
through
those
in
case
you
haven't
been
following
the
details
on
the
list.
D
There's
SOC
is
system-on-chip,
so
there's
a
single
chip
on
on
the
device
and
it's
obviously
the
most
simplistic
case
it
contains
typically
in
the
same
package,
contains
flash
and
aram
and
and
also
father
prefers
in
so
there's
only
a
single
firmware
image
that
needs
to
be
updated
and
it's
sort
of
like
the
execute
in
place.
That
David
is
often
referring
to
where
he
wants
to
sort
of
like
not
move
code
around
on
the
on
the
flash,
because
it
it's
obviously
consuming
a
lot
of
energy.
So
that's
that's
the
simplest
most
simplistic
case.
D
D
So
there's
a
case
where
so
the
cpu
supports
the
scheme
and
in
general,
the
way
how
it
works
is
the
secure
mode
will
then
do.
The
update
will
then
decide
on
where
things
go
and
maybe-
and
you
need
to
figure
out
on
what
you're
actually
updating.
So
you
may.
The
secure
mode
may
just
update
the
image
on
the
normal
site
sort
of
mate.
Then
there
needs
to
be
a
way
to
indicate
on
like
what
a.
What
are
you
actually
updating
which
part
of
the
component
and,
of
course,
independently
or
potentially
both
of
it?
D
So
you
need
to
have
a
way
to
describe
this
in
the
inner.
Manifest
are
more
complicated
scenarios
when
you
have
a
dual
CPU
that
actually
use
a
shared
memory
and
they
access
the
data,
so
there
may
be
still
or
there
has
to
be
a
mechanism
to
prevent,
but
to
have
some
locking
mechanism,
but
typically
one
CPU,
then
controls
the
update
process
and
swaps.
D
Everything
out
so
the
others
see
it's
similar
to
the
former
model,
but
just
separate
it
out
into
two
CPUs,
rather
than
one
CPU
having
a
secure
non
secure
petition,
and
this
is
just
having
a
sort
of
two
CPUs
doing
these
different
tasks.
He
also
provided
a
link
to
some
handsome
IOT
hardware.
It
does
exactly
that.
L
Oh
sorry,
Keith
Moore
I'm,
looking
at
these
models
and
I,
it
seems
like
that.
There's
a
lot
of
value.
Vat
I
hear
that,
for
instance,
I
worked
with
the
CPU
that
had
a
lot
more
non-volatile
Ram
that
Co
who'd
run
out
of
then
it
actually
had
RAM.
So
when
you're
actually
updating
the
firmware
for
this,
you
have
to
update
it
in
slices
and
you
have
to
update
each
one
of
those
slices
one
at
a
time
and
have
the
thing
keep
running
while
you're
doing
it.
L
G
L
You
know
a
BeagleBone
is
a
system
on
chip.
Fundamentally,
that's
basically,
yet
it
runs
up
into,
and
you
know
it
can
do
all
kinds
of
things
and
you
you
often
have
a
need,
in
my
experience,
to
update
things
in
layers
because,
for
instance,
you
don't
want
to
pay
the
communications
cost
of
updating
the
entire
image
of
something.
G
L
M
N
N
D
And
then
one
other
you
can
reach
through
the
text
in
the
document
itself,
which
is
on
Everett,
but
the
other
model
is
where
you
have
a
bus
between
the
CPUs
and
you
need
to
indicate
in
the
manifest
on
which
CPU
on
the
device
you
actually
updating.
But
it's
not
in
the
same
sort
of
address.
Basically
what
it's
just
separate.
D
But
the
encryption
of
the
manifest
is
something
that
surfaced
in
other
discussions
and
we
didn't
I,
don't
think
we
currently
have
that
functionality.
So
that
may
be
an
item
worthwhile
to
think
about
a
little
bit
whatever
you
want
that
and
whether
there
are
some
privacy
implications
in
certain
situations
on
what
benefits
we
could
actually
get
from
this.
So
I
see
it
doesn't
as
an
open
issue
that
may
require
further
further
debate.
D
B
The
on
the
mail
list,
if
you
take
a
look,
you'll,
see
that
the
Human
Rights
review
person
was
saying
that
when
a
device
is
easily
associated
with
a
human,
that
is
when
this
becomes
an
issue,
and
so
I
think
we.
We
need
to
recognize
that,
but
at
the
same
time,
maybe
not
overcomplicate
the
entire
architecture,
because
not
all
devices
have
that.
D
Problem,
definitely
definitely
in
fact,
I
would
even
go
as
far
as
seeing
many
devices
don't
have
that
problem,
because
the
manifest
doesn't
include
user
information
right
indirectly,
there
may
be
in
some
cases,
so
I
think
we
need
to
study
this
a
little
bit
further
to
figure
this
out.
I
was.
A
O
Benkei
no
you're,
just
pointing
out
that
you
know
the
distinction
between
devices
that
have
been
associated
human
and
those
that
don't
there's
kind
of
a
funny
question.
And
you
know
we
hear
about
all
these
issues
where
you
can
dn
on
Elias,
anonymous
datasets
and
that
sort
of
thing.
So
there's
lots
of
sort
of
side
channels.
If
you
will
that
can
make
this
pop
up
more
often
than
you
might
yeah
sure.
P
Up
next
right,
yeah,
this
is
from
grocery
bod
I
think
there
are
general
advantages
to
encryption
of
the
firmware
imaging
manifest.
But
it's
up
to
the
working
group,
whether
the
draft
needs
to
sect
requirement
levels
for
devices
associated
with
humans
or
not
and
recommends
encryption
of
the
manifest,
also
because
it
contains
device
info.
K
So
Dave
they
were
individual
saving
that
trip
over
there.
If
the
goal
was
to
allow
it
without
complicating
anything
else,
if
there's
not
another
convenient
mechanism
right,
you
can
always
treat
the
manifest
as
like
another
encrypted
binary,
and
then
you
decrypt
it
the
same
way.
You
have
the
binary
and
then
recurse.
D
Next
steps,
so
we
still
have
to
do
editorial
cleanup
on
a
document
and
get
some
feedback
from
the
working
group
I
also
from
earlier
discussions,
and
there
was
a
desire
to
have
more
text
around
the
bootloader
our
design
and
how
it
in
the
implications
are
for
the
whole
processing
of
this.
So
I
haven't
gotten
to
that.
Yet
there's
also
a
need
for
better
lined
with
the
information
model,
because
the
terminology-
sometimes
one
version
of
the
document-
lags
a
little
bit
behind
so
those
that
those
are
the
major
items.
I,
don't
think.
D
M
D
Information
model
so
version
one
was
published
in
time
for
the
deadline
and
version
zero
was
published
at
in
preparation
for
the
virtual
interim
meeting.
If
you
look
at
the
diff,
there
are
lots
of
changes,
so
I
can't
go
through
all
of
them,
and
some
of
them
are
probably
a
little
little
out
of
sync
with
the
presentation
that
Brennan
is
giving
when
he
talks
about
the
most
recent
version
of
the
manifest
format.
So
I
keep
those
I
focus
just
enough
on
a
few
core
issues
and
we
added
two
threats
regarding
the
unqualified
firmware.
D
So
here's
the
case
that
was
discussed
and
I,
hopefully
appropriately
captured.
So
imagine
you
have
device
and
network
operators
and
the
device
operator
creates
the
firmware
or
has
the
works
with
the
also
to
do
so
in
a
network
operator
needs
to
decide
whether
the
this
specific
IOT
device
with
their
firmware
is
fit
for
purpose
on
that
network,
which
may
be
a
situation
in
a
in
some
of
the
critical
infrastructure
environments
in
the
device
operate.
The
managers
devices
that
are
deployed
in
all
sorts
of
different
networks,
and
so
the
attack
scenario
is
the
following.
D
So
it's
perfectly
like,
from
a
signing
point
of
view,
it's
perfectly
fine,
but
just
not
complying
to
the
policy.
The
other
cases
where
you
have
multiple
devices
that
interoperate
they
are
working
on
the
same
network.
So
we
have
only
one
Operator
rather
than
two
but
multiple
device
operators
and
you
so
some
some
of
the
devices
are
manufactures
and
managed
by
device
operator.
A
and
other
spy
device
operate.
The
B
and
now
is
a
firmer
release
for
device
operator,
a
that
breaks,
the
interoperability,
a
compatibility
with
those
of
the
device
operator
B.
D
So
the
network
operator
may
want
to
have
some
saying,
or
some
may
need
to
qualify,
which
one
of
those
firmware
images
are
actually
allowed
to
be
used
in
this
in
his
network.
Irrespectively
of
what
and
device
operate
diminishes
them,
which
can
obviously
be
used
to
cause
denial
of
service
or
potentially
other
other
problems.
So
we
added
those
two
threats,
but
I
don't
remember
who
suggested
them,
but
I
covered
them.
There's
some.
D
So,
for
example,
you
have
a
device
that
has
on
chip
flash
and
off
chip
flash,
so
those
would
be
stored
differently,
whereas
in
the
homogeneous
storage
architecture
we
are
talking
about
storage,
of
firmware
images
or
different
components
in
the
same
way,
so
they
may
be
just
in
different
address
spaces
in
on
the
flash.
So
those
two
terms
so
for
the
for
the
case
with
multiple
microcontrollers
there's,
there's
a
need
to
have
our
component
identifiers
to
actually
distinguish
between
the
places
where
these
firmware
images
have
to
go
in.
D
What
the
manifest
needs
to
provide
is
sort
of
a
dependency
structure,
because
it
it
has
to
sort
of
get
the
to
the
code
and
the
data
somehow
somehow
aligned.
So
you
can't
just
swap
out
one
and
not
have
any
say
anything
about
the
other
one
that
this
firmware
image
then
depends
on.
So
this
is
sort
of
the
dependency
structure,
whatever
the
name
in
and
in.
In
some
cases
you
have.
D
The
firm
was
split
into
multiple
chunks,
maybe
different
libraries
that
you
update
separately,
maybe
for
performance
reasons
or
for
bandwidth
or
conserving
bandwidth,
and
so
you
also
have
to
create
the
dependency
between
the
different
firmware
images
that
you
allow
on
on
a
device
we
had
Kay.
We
had
a
few
examples
and
they
also
in
a
document
where
we
have
more
sophisticated
cases
where
multiple
different
versions
are
sort
of
supported
or
possible
versus
having
only
a
very
specific
from
our
firmware
version
supported
on
a
device.
D
So
we
have
those
added
and
in
to
get
a
bit
those
use
cases,
obviously
the
corresponding
information
elements
added
as
well
I'm
going
to
talk
about
them
a
little
bit.
There's
one
use
kit
that
David
Brown
suggested
the
rollback
use
case,
which
is
not
yet
covered
in
the
in
the
document,
and
so
he
has
the
he
came
up
with
this
case
I'm
in
talking
to
some
some
others.
D
It's
a
about
a
battery
powered
device
that
is
connected
to
a
bandwidth,
constraint,
network,
think
about
the
low
power
wide
area
network
and
the
device
keeps
the
old
firmware
around
aren't
just
in
case.
It
needs
to
do
a
rollback,
so
it
has
multiple
slots
for
the
firmware
image
and
then
the
document
doesn't
say
on
how
such
an
update
would
happen
because
it
always
talks
about
advancing
the
firmware
images
in
rolling.
Obviously,
when
you
advance
the
film
image,
you
need
to
provide
them
new
firmware
image
along
with
it,
so
he
was.
D
He
thought
that
it
would
be
good
to
also
describe
this
case
where
the
rollback,
the
new
manifest,
which
contains
a
new
sequence,
number
actually
doesn't
contain
the
firmware
image
because
it
is
already
on
the
device
and
so
and
it's
impossible
already,
with
the
way
how
the
manifest
is
structured,
but
it's
just
not
described
and
maybe
a
little
misleading.
So
he
thought
it
would
be
worthwhile
to
cover
this
case.
D
Q
Robin
Wilton
from
Internet,
Society
I'm,
so
just
thinking
of
some
of
the
security
implications
of
this,
it
strikes
me
that
having
a
rollback
mechanism
for
large
networks
of
distributed
devices
could
open
you
up
to
a
kind
of
downgrade
attack.
So
if
the
purpose
of
the
firmware
upgrade
was
to
add
a
security
function
and
someone
can,
at
a
mass
scale,
roll
that
back
on
all
the
devices
they
open
those
devices
up
to
be
a
botnet.
For
example,
I'm
in.
D
This
specific
case
I,
don't
think
so
because
the
aim,
because
the
entity
has
to
or
the
party
rolling
out
the
firmware
update,
actually
has
to
create
a
new
manifest.
A
new
manifest
has
a
new
sequence,
Tomaso
it's
newer
than
the
ones
that
device
had
seen
before,
but
I
think.
The
optimization
here
is
really
in
the
area
of
not
sending
the
image
itself.
R
I
Brenden
Europe,
the
intent
with
this
mechanism
is
that
it
it
proves
the
intent
of
the
author.
So
if
the
author
says
actually
the
firmware
that's
just
been
rolled
out
is
not
fit
for
purpose
and
we
need
to
go
back
to
the
previous
firmware.
They
have
to
prove
their
intent
to
go
back.
That's
the
defense
against
creating
botnets
the
the
issue
in
the
botnet
situation
is
that
you
don't
have
the
intent
of
the
author.
The
author
hasn't
proven
that
they
want
to
roll
back.
Then
you,
you
end
up
with
a
problem.
I
If
the
author
can
prove
that
they
intend
to
roll
back,
then
that
eliminates
that
possibility
now
I'm
not
saying
that
they
don't
have
vulnerabilities
and
they're
all
firmware
they
might
well.
But
if
there
is
an
intent
that
you
can
prove
to
go
back,
then,
presumably
they
have
a
reason
for
that,
and
that
is
open
to
them.
They
could
just
create
the
same
firmware
again
and
ship
it
again,
and
that
would
give
the
same
result,
but
this
does
it
in
a
slightly
optimized
way.
Well,
maybe
a
very
optimized
way.
G
S
G
S
D
D
I
want
to
get
the
time
to
do
Brendon
because
he
has
this
new
structure,
so
referring
back
to
the
discussion
earlier,
with
the
different
types
of
use
case
and
different
types
of
sort
of
more
sophisticated
hardware
components.
So
this
we
have
this
concept
or
this
element
of
storage
location
and
which
then
allows
you
to
distinguish.
For
example,
are
you
updating
in
OS?
Are
you
updating
in
application?
This
is
sort
of
the
the
to
storage
location
case.
D
Are
you
putting
something
on
a
file
system,
so
that
would
be
the
path
in
the
file
system,
or
are
you
putting
something
into
flash
memory
where
exactly
in
flash
memory?
Do
we
actually
put
it
this
sort
of
like
the
offset
or
address
of
the
space
where
you
put
it?
So
that's
an
element
that
that
has
been
added
or
has
been
clarified.
There's
also
anything.
D
There's
also
this
component
identifier,
which
was
added
because,
in
the
case
of
heterogeneous
storage
architecture,
this
this
storage
identifier,
that
I
just
talked
about,
is
not
sufficient
to
actually
identify
where
to
put
the
information
that
firmware.
So
it's
component
identifier
was
was
added
as
a
new
element,
the
conditions
and
that
the
condition
element
was
there
all
along.
D
But
there
was
a
lot
of
confusion
and
discussion
so
on
on
the
different
elements,
and
it
was
then
later
split
into
two
types
of
conditions,
preconditions
and
postconditions,
and
that
change
has
been
made
in
a
manifest
format
but
hasn't
been
populated
back
into
the
information
model
document.
So
you
still
have
a
little
bit
of
an
out
of
sync
situation:
yeah,
custom,
custom.
F
M
D
So
probably
the
most
dramatic
change
was
also
it's
currently
out
of
sync
is
and
I
included
the
link
to
an
email
here
from
from
Brandon
on
a
list
about
the
sort
of
changes
on
the
directive
elias's
and
dependencies
which
had
been
turned
into
a
new
structure
resources
and
that
text
isn't
there.
Yet,
in
the
information
model
document
we'll
get
to
that
in
in
a
little
while
Hannes,
can
you
go
back
to
slides
I?
Don't
think
you
finished
your
thought
about
conditions?
D
What
work
needs
to
be
done,
so
the
work
that
needs
to
be
done
there
is
to
take
the
the
split
or
incision
to
split
the
conditions
into
pre
and
post
conditions
also
reflect
that
into
the
information
model
document.
Currently
it's
not,
and
this
one
is
brand
new
services
are
also
not
there
and
I
think
this.
This
is
something
the
group
hasn't,
maybe
not
even
decided
for.
U
J
D
Things
down
in
a
more
specific
style
for
some
reason,
and
so
you
see
things
being
somewhat
misaligned.
So
if
I,
if
I
would
do
that
again,
I
would
probably
have
just
one
document
in
split
later
on
when
I
actually
figured
out
exactly
how
the
structure
looks
like,
but
it's
too
late
for
that,
but
okay
and
I
hand
it
over
to
the
Brendan
or
and
yet
a
comment,
yeah
sure.
U
U
D
G
A
And
the
information
document,
the
documents
switch
between
uppercase
and
lowercase
must
so
it's
kind
of
hard
for
me
to
know
when
I'm
reviewing
the
document,
what
you
intend
to
be
a
requirement
and
what
you
don't.
So,
if
you
could
update
your
section
two
to
use
the
new
vcp
on
uppercase
and
lowercase
requirements,
then
really
helpful
for
me
as
a
reader.
Okay,
thank
you.
Yeah.
D
D
I
So
the
I
want
to
start
by
saying
that
the
manifest
serialization
is
under
a
lot
of
flux,
so
I
am,
for
instance,
there's
this
whole
thing
that
Hank
mentioned
about
the
the
manifest
processors
and
resources
and
targets
and
I
honestly
now
believe
that
that's
probably
a
mistake
and
that
there
is
a
better
way
of
handling
it,
which
I'll
talk
about
in
a
moment.
So
suggestions
welcome,
there's
a
lot
to
be
done
yet
to
get
this
to
a
point
where
I
think
we
can
standardize
it
brand-new.
F
I
Okay,
so
next
slide,
please,
there
are
a
lot
of
open
issues.
The
first
one
as
Hank
brought
up
is:
should
the
primary
object
be
an
array
or
a
map,
and
then
there
is
the
question
of
whether
we
should
use
a
graph
as
I
described
in
manifest
0
2
I'm,
not
convinced,
and
but
if
we
use
trees
to
to
deal
with
this,
then
there's
a
there
are
open
questions
of
how
they're
overridden
represented
and
whether
or
not
they
break
any
use
cases.
I
A
I
Sure,
ok,
I
should
write
sections
be
severable,
so
we
we
introduced
the
cons
of
separable
text
at
the
art.
Well,
I.
We
started
talking
about
it
during
the
hackathon
at
the
virtual
interim
meeting
at
the
idea
behind
this
one
is
that
we
cut
text
out
for
devices
that
don't
require
it
text
is
meant
to
be
human,
readable
devices,
don't
really
need
to
process
it
and
it
can
increase
data
sizes
so
by
making
them
detached
I
believe
is.
The
term
is
used
in.
Most
containers
are
most
crypto
containers.
I
Q
G
I
To
address
explicitly,
it's
also
something
that
we
might
need
to
address
one
level
higher
up
with
the
concept
of
severing
more
sections
of
the
manifest,
rather
than
just
the
text.
Maybe
it's
possible
that
we
could
wrap
that
particular
problem
up
in
one
of
the
sections
that
the
manifest
references,
while
still
maintaining
the
ability
to
still
maintaining
the
ability
to
process,
manifests
at
intermediate
steps,
which
is
important
for
routing
considerations.
I
Among
other
things,
it
we
need
to
work
out
the
encoding
of
processing,
steps,
directives
and
conditions
and
extensions
and
there's
a
lot
of
enums
used
throughout
the
manifest,
and
there
are
going
to
be
Ayana
implications.
Because
of
that
and
with
that
list
of
open
issues,
shall
we
dive
into
a
couple
of
them
a
ray
versus
map,
I'm
still
more
set
on
arrays
than
maps,
largely
because
most
of
the
fields
are
mandatory.
I
F
So
Cass
Mela
again
we
had
this
interesting
hackathon
in
June.
The
tennis
talked
about,
and
one
piece
of
feedback
that
was
pretty
strong
from
member
Mendez
on
the
embedded
side
was
that
they
really
like
to
do.
Put
it
pauses
and
pauses
essentially
means
that
the
control
flow
in
in
the
program
that
actually
makes
use
of
the
data
it's
kind
of
bound
to
the
civilization
sequence
in
which
the
data
comes
in,
and
that
of
course
means
the
more
deterministic
the
more
predetermined.
The
series
agent
sequence
is
the
easier
it
is
to
run
this
pull
apart.
F
So
that's
actually
an
observation
that
that's
both
relevant
for
this
and
for
the
next
question.
So
for
the
array
versus
map
decision,
the
obvious
advantage
of
a
map
is
that
it's
easier
to
extend
the
disadvantage
is
that
you
are
not
predetermining
predetermine
a
the
sequence.
Now
you
can
do
some
things,
of
course,
for
instance,
if
you
should
go
for
consistent
encoding,
you
could
say
the
fluids
in
would
not
have
to
be
serialized
in
a
sorted
way,
and
so
on
that.
That's
one
way
to
fix
this,
but
I
agree
with
your
assessment
right
now.
F
Essentially,
graphs,
what
arrays
are
two
maps
so
trees
again
allow
Apple
aza
to
tie
its
controversial
to
the
sequence
in
which
things
come
in.
Why,
with
a
graph
that
may
be
more
complicated?
That's
not
always
true,
because
there
are
some
some
elements
of
a
graph
that
you
would
just
stash
away
and
and
then
use
in
the
following.
So
this
is
not
that
quite
as
clear
cut
as
it
was.
It's
not,
but
is
a
general
observation.
I
think
trees
are
actually
easier
to
process
in
an
ability
limitation.
F
U
Hi,
this
is
Hank
again
any
Asha.
Of
course,
trees
are
easier.
That's
that's
a
plus,
also
I,
think
out
of
twelve
fields.
Five
are
mandatory
and
seven
optional.
Think
it's
the
wrong
way
around.
Also
I
think
we.
Why
not
do
one
thing
and
also
not
not
not
to
the
other
I
mean
there
could
be
a
fixed
envelope
and
we
have
one
that
is
the
cozy.
U
The
payload
resides,
and
maybe
the
payload
is
the
staff
member,
and
we
put
everything
that
is
about
the
metadata
into
the
secure
header,
for
example
just
spinning
from
the
top
of
map.
Okay,
so
we
can,
we
might
be
able
to
leverage
both
benefits
of
maps
and
arrays
and
don't
have
to
stick
with
one
necessarily
I
think
also
I
would
agree
with
the
the
idea
that
if
you
want
to
prove
something
out
of
a
fire
and
a
district
offset,
you
have
some
additional
problems
of
heading
I.
Think
it's
like
word
wise
copy,
I.
U
Think
there's
a
brought
up
on
the
email
list.
I
think
this
photo
brought
up
at
the
ITF
hackathon
Hannah's.
Maybe
you
can
remember
I,
don't
really
know
the
source
anymore,
but
there
was
this
idea
that
were
just
blindly
I
can
and
grab
into
the
manifest.
If
there's
a
firmware
in
there
and
put
that
out
because
word
wise
copy,
there
was
some
very,
very,
very
strict
and
naive.
We
there's
like
basically
want
to
do
nothing.
I
want
to
be
sure
where
it
is
going
to
receive
at
the
end.
U
Maybe
it
will
never
be
that
easy,
but
I
don't
think
that
maps
are
such
a
big
disabler
for
that,
because
at
the
moment
we
are
looking
if
an
array
is
empty
and
if
it's
not
empty,
there's
an
error
in
it
and
that
might
be
empty,
and
it's
also
very
a
lot
of
work.
I
mean
looking
for
members,
basically
the
same
effort,
so
I
don't
think
that's
huge.
A
Dave
Walter
Meyer
as
an
individual
I'm,
just
to
kind
of
touch
on
some
of
the
points
that
Hank
and
Carsten
made
I
I
think
my
preference
would
be
for
using
a
map
in
this
case,
for
a
number
of
reasons.
I
believe
using
a
map
will
actually
reduce
the
amount
of
branching
I.
Don't
like
the
idea
of
supporting
both
arrays
and
maps,
because
that's
another
source
of
branching
and
and
and
and
parsers
but
I,
believe
a
map
will
reduce
branching
because.
A
The
code
points
that
are
effectively
used
as
the
as
the
labels
can
be
used
to
to
drive
code
like
Carson
was
was
saying
in
in
pulled
parsers
I
think
it
also
gives
us
a
way
to
add
extensibility
into
into
the
model
by.
You
know,
by
allocating
additional
code
points
for
different
kinds
of
information
that
we
may
want
to
include
in
the
manifest
in
the
future.
A
If
we
get
something
wrong
with
our
current
representation
of
information
within
the
manifest,
it
allows
us
to
issue
a
new
code
point
for
maybe
an
alternative
to
that
in
the
future,
which
I
think
also
eliminates
a
lot
of
the
need
around
versioning
within
within
the
the
manifest
effectively
the
parser
can
work
off
of
the
the
code
points
that
that
it.
You
know
that
it
understands
from
from
that
perspective,
so
I
think
I.
Think
using
a
map
has
a
number
of
advantages
as
a
solution
over
over
an
array.
A
F
Two
quick
comments:
one
anything
that
can
help
avoid
versioning
and
to
weather.
An
array
really
gives
you
a
lot
of
advantages
over
a
map
depends
a
lot
on
whether
you
can
process
these
elements
in
isolation.
If
you'll
need
to
see
the
whole
picture
anyway,
then
then
the
map
is
fine,
but
if
there's
something
that
you
specific,
then
a
map
is
fine,
because
it
doesn't
make
a
difference
in
which
sequence
you
start
processing.
It.
F
N
Europe
alright,
first
point
I'll
make
just
in
response
to
that.
The
inin
cozy
curve
actually
see
bore
if
you
use
a
canonical
format
which
we
should
be
using.
If
we're
signing
these,
the
map
will
be
in
a
specific
order.
It's
sometimes
a
confusing
order.
Based
on
how
the
numbering
system
works.
All
positive
numbers
come
before
negative
numbers,
that
kind
of
thing,
and
then
it
depends
on
the
size
of
the
number
I
guess
the
point
I
wanted
to
make.
N
Perhaps
it
would
be
useful
in
our
document
if
we
actually
identify
the
processing
sequences
that
will
happen
I,
especially
this
notion
of
a
pull
parser
that
that's
a
great
way
to
describe
by
the
way
what
I
was
trying
to
state
that
the
data
needs
to
be
parsed
without
reading
it
into
a
data
structure.
These
are
some
of
these
are
very
constrained
devices
that
are
acting
on
the
data
and
I
think
that
needs
to
be
really
taken
into
consideration,
perhaps
even
included
in
the
document
how
this
will
be
processed.
So
that's
just
my
comment.
F
F
So
one
observation
there
is
something
called
canonical
encoding
in
FC
1749.
It's
a
recommendation,
not
a
specification.
The
recommendation
for
how
an
application
could
be
find
the
economical
encoding.
We
are
no
longer
happy
with
everything
exactly
that's
in
there,
so
we
are
going
to
in
the
revision.
That's
going
on
Zeebo
working
group.
We
are
going
to
define
a
slightly
different,
consistent
encoding,
and
the
main
different
difference
here
is
that
the
new
one
will
have
a
map
ordering
that's
slightly
less
surprising.
F
It
will
still
have
a
negative
after
the
positive
ones,
maybe
that
there
is
a
bug
in
the
location
of
major
types,
but
at
least
you
don't
have
to
look
at
the
links,
because
that
really
hurts
implementations
a
lot.
So
the
other
observation
is,
you,
don't
have
to
be
canonical
or
consistent,
choose
I'm,
so
you
are
free
to
choose
anything
else,
but
I
think
the
the
can
you
make
your
choice.
You
want
to
make
life
easy
for
the
embedded
side
and
may
want
to
accept
some
hardship
on
the
side
that
actually
builds
the
manifest.
O
Great
rinkie
luck
just
think
about
David
Valle.
Tomorrow's
comment
about
using
the
map
as
a
extensibility
point
generally,
when
you're
thinking
about
sort
of
extensibility
thing,
you
want
to
consider
the
possibility
that
a
new
extension
might
be
critical
and
that
if
it
appears-
and
you
don't
understand
how
to
purse
it,
you
just
fail
entirely.
I'm,
not
sure
if
there's
a
good
way
to
incorporate
that
with
the
because
I'm
a
poor,
not
Superman,.
U
Think
again,
I'm
just
picking
up
on
the
previous
comment:
yeah,
it's
bad.
If
you
do
not
do
updates
before
updates,
because
if
you're
uncertainly
unprepared
for
something
that's
in
the
manifest
that
should
be
support.
What
about
the
client?
You
staged
something
wrong,
I!
Think
so,
please
bill
could
compare
campaigns,
that's
important!
All
the
wavy
losses
so,
and
that's
one
but
I'm.
Also
the
map.
Thingy
I
was
my
point.
Yeah,
the
the
canonical
ordering
is
an
option,
I
think
and
yes,
everything
that
makes
it
less
necessary
to
look
for
versioning
and
the
new
canonical.
P
U
The
what
was
mentioned
before
about
that
you
would
like
to
have
a
pointer
to
something
from
the
manifest
another
copy
of
it,
because
smaller
constant,
no
device
but
but
benefit
from
that.
That's
just
a
true
problem.
That's
that's!
That's
not
not
a
problem
of
of
either
Maps
arrays.
All
this
should
manifest
at
all.
I
think
and
I.
Think
Chinese,
simple
care
just
do
it
just
copies
it.
I
G
I
I
I
take
the
the
points
that
are
made
and
I,
particularly
like
the
idea
of
pull
parser
and
I.
Think
the
that
one
thing
we
might
be
able
to
do
here
is
try
and
actually
merge
these
two
concepts.
So
what
I
mean
by
this
is
that
if
we
deliberately
flaunt
canonical
encoding
and
put
elements
in
the
order
that
is
needed
by
the
target
device,
then
we
can
actually
get
perhaps
the
best
of
both
worlds.
K
N
David
go
ahead,
it's
one
thing:
I
pointed
out
on
the
sea
bore
mail,
the
yes,
the
Seabourn
mailing
list
in
the
manifest
that
we
currently
have.
We
use
a
syntax
that
is
allowed
by
the
grammar
in
the
sea,
bore
spec,
but
not
explained
what
it
means,
which
is
basically
an
array
of
pairs
that
may
be
a
useful
format.
It's
basically
treated
like
a
map,
but
the
ordering
can
be
specified
so
I,
don't
know
if
that's
useful,
to
contribute
to
C
bar
in
that
regards.
B
K
I
I
G
I
I
The
component
identifier,
I've
got
listed
as
an
array
of
B
strings,
following
on
from
discussions
at
the
hackathon
I
have
come
to
the
conclusion
that
a
component
identifier
and
a
storage
identifier
together
are
just
a
generalization
or
sorry
there-there's,
a
specialization
of
an
array
of
identifiers.
So
let's
just
use
an
array
of
identifier
z'
then
this
can
be
thought
of
as
a
as
a
path.
I
I
Alright,
so
this
explains
how
the
how
a
particular
thing
that
you
install
gets
installed.
You
start
by
having
a
component
identifier
and
then
a
list
of
processors.
Now
processors
are
things
that
manipulate
the
data
in
some
way,
either
by
producing
it,
if
it's
the
resource
type
or
by
decrypting
decompressing
on
Delta
relocating
all
of
those
sorts
of
operations.
I
Allow
override
tells
you
whether
the
asset
installation
info
can
be
replaced
by
a
dependent,
manifest
and
extensions,
as
previously
discussed
may
not
be
needed.
If
this
is
coded.
As
a
map
next
slide,
please
so
why
not
leave
container
information
in
payloads
it's
so
that
we
can
reject
the
manifest
if
a
device
can't
process
it-
and
this
is
particularly
important
for
low
bandwidth
and
not
using
enums
for
aggregate
formats
is
largely
due
to
the
specialization
that's
necessary
to
do
it.
A
A
I
A
I
Q
A
One
one
option
here
might
be
to
use
to
to
maybe
provide
for
you
no
special
specification
required
or
standards
action
for
one
type
of
extension
and
maybe
private
use
for
another,
so
you
might
want
to
maybe
use
like
positive
values
for
for
specification
required
and
negative
integers
for
private
use.
We
should
maybe
think
about
how
this
extension
point
might
be
used
a
little
bit.
You
know
going
forward
and
how
we
might
want
to
manage
manage
those
extensions
I
mean.
Maybe
that's
a
general
comment
too,
for
all
places
where
we
have
extension.
A
U
Hi,
this
is
Hank
again.
Okay,
looking
at
this
slide
up
right
now,
I
see
extensions,
that's
fine!
It's
a
map
that
is
basically
everything
and
it's
huge
and
there's
also
the
idea
of
having
a
CDDA
extension
point.
So
this
is
for
I
think
you're
doing
it
quickly
by
yourself
with
negative
numbers,
for
example.
Yes,.
Q
U
If
you
want
to
do
with
the
positive
numbers,
maybe
indicate
that
you
should
do
an
acidity
a
data
definition
extension
and
not
just
arbitrarily
for
more
stuff
into
the
extension
map,
because
this
is
that
it's
not
very
defined
at
some
point.
If
you're
really
going
for
an
extension
of
the
manifest
which
would
write
a
draft
about
it
and
use
this
CDDA
data
division,
language
extension
point
and
not
the
extra
map,
yeah
I-
think
that's
important
to
highlight.
Also
I,
agree.
Also
I
think
you
have
only
one
member
in
the
inputs.
I
U
I
Okay
and
the
other
one
is
the
map
of
inputs.
Now
again,
that
is
a
specialization
that
deals
specifically
with
Delta
updates
or
differential
updates,
and
that's
because
you
need
a
local
input.
The
thing
that
you're
comparing
against
and
the
remote
input
the
different
the
stream
of
differences.
Okay,.
U
I
U
I
I
I
So
an
example:
here
all
right:
we
have
a
raw
binary
payload,
so
there
are
no
arguments
needed
then
an
encrypted
binary
payload
is
the
next
possibility.
You
would
need
a
key
identifier,
an
algorithm
identifier,
those
who
both
need
to
be
arguments
to
the
to
the
payload
descriptor.
Then
the
possibility
of
encrypted
compressed
binary
or
encrypted
compressed
Delta
payload.
You
can
see
how
each
one
of
these
has
a
different
set
of
arguments
that
are
needed
to
describe
it
properly
and
when
we
go
through
this
you
could.
I
I
Said
the
same
thing,
it
would
be
easy
to
miss
if
a
reasonable
combination
of
supported
steps,
so
we're
I'm,
suggesting
that
we
describe
each
step
instead,
as
any
each
one
can
have
a
defined
structure.
They
can
all
be
represented
in
the
same
way,
but
then
we
have
to
define
how
flow
is
described
and
because
of
Delta.
We
know
that
flow
is
a
tree
rather
than
a
linear
sequence,
and
a
shared
resource
between
two
steps
might
turn
that
flow
into
a
graph.
I
But,
as
was
mentioned
earlier,
graphs
make
constraint,
processing
hard,
so
using
multiple
trees
instead
is
probably
the
right
answer
and
I
haven't
seen
a
lot
of
examples
of
a
shared
resource
so
and
even
if
they
were
I,
don't
think
that
would
increase
data
size
or
make
processing,
particularly
harder,
so
I
think
it's
probably
the
right
choice
to
defined
it.
The
flow
between
these
steps
as
a
tree
rather
than
a
linear
sequence,.
I
Next
slide,
please,
so
the
way
that
this
would
be
constructed
together
is
that
each
asset
would
have
a
tree
that
defines
the
installation
process,
as
I
defined
above,
to
reduce
the
nesting
depth
in
the
parser,
the
trees
encoded
as
a
list.
Now
this
is
important
for
early
verification.
It
makes
it
easy
for
a
device
to
check
that
it
supports
each
of
the
processing
steps
that
are
defined
without
actually
having
to
construct
the
tree
or
parse
down
a
deep
tree.
I
Resources
are
also
encoded
as
processors,
but
with
no
inputs,
or
rather
with
inputs
that
are
redefined
to
either
URIs
or
component
identifiers
and
an
asset
is
Dafoe,
is
designated
as
something
that
has
a
single
tree
that
feeds
it
and
the
output
nodes
that
I
had
mentioned
earlier
can
be
marked
as
none
over
rideable.
That's
where
the
the
allow
override
or
allow
alias
I
forget
what
I
called
it.
I
is
in
the
CD
DL
previously
and
again,
dependent
manifests
can
override
any
installation
tree
and
that's
the
whole
tree.
That's
not
marked
as
none
over
rideable.
Now.
I
So
in
this
case
it
redefines
the
installation
tree
and
the
device
then
can
pick
up
the
installation
tree
out
of
the
dependent,
manifest
and
still
validate
the
asset
out
of
the
canonical
manifest
next
slide.
Please
so
how
this
would
work
and
for
a
raw
binary
payload,
you
would
have
a
component
identifier.
I
This
is
to
the
explaining
how
it
gets
installed.
You'd
have
a
component
identifier
and
a
resource,
and
that
would
be
all
of
it.
The
whole
installation
information
section,
the
asset
information
would
be
exactly
the
same.
You
would
have
a
component
identifier
encoding
as
raw
binary
and
what's
not
listed
here,
the
size
and
the
digest
next
slide.
Please
here
again
a
delta
payload
e.
I
Information
we'd
again
have
that
component
identifier,
so
that
the
device
knows
which,
where
to
store
this
and
can
link
the
asset
information
with
the
installation,
information,
the
encoding
as
raw
binary
and
the
input
node
I
think
shouldn't.
Be
there
right,
I
missed
a
section.
I
was
supposed
to
delete.
My
apologies.
There's
an
error
in
the
slide.
Please
disregard
the
last
bullet
point.
There
would
be
a
an
additional
digest.
I
D
For
me,
it
would
be
interesting
to
know
whether
we
sort
of
made
a
conclusion
on
going
to
the
map
structure
away
from
the
array.
That
was
the
first
point
that
Brendan
brought
up,
and
the
second
thing
is
whether
we
want
to
go
forward
with
this
sort
of
processing
structure
that
that
Brendan.
D
Presented
because
that
would
be
obviously
useful
in
going
forward
and
refining
it.
We
had
a
longer
discussion
on
the
mailing
list
on
those
topics
or,
if
there's
a
different.
A
different
direction
then
probably
would
be
also
good
to
discuss
this
as
we
are
going
to
move
forward.
As
we
update
the
this
data
model
document,
we
also
have
to
then
get
the
corresponding
information
doctrine,
information
model
document
in
sync
dealing
with
some
of
the
conditions
and
the
already
asset
and
the
other
things
it
needs
to
line
up.
Otherwise,
it's
very
difficult
to
understand,
order
for
thing.
B
H
B
U
D
Honus
is
coming
back
to
the
mind,
but
it
seems
at
least
on
that
issue
from
the
folks
in
the
room
and
there.
Of
course,
there
are
other
people
on
the
mailing
list,
but
there
was
a
reference
more
to
them
on
a
map
site
rather
than
the
area
site.
At
least
that's
how
I
understood
the
discussion.
B
V
Dave
camp
with
Department
of
Defense:
if
the
information
model
says
that
you
have
an
ordered
map,
that
is,
then
you
require
a
serialization
that
will
preserve
that
ordering
property
I'll
notice
that
that
Python,
just
recently
decided
to
make
their
maps
have
an
ordering
property
to
it.
So
egg
says:
well,
you
could
use
a
two-dimensional
array,
but
a
map
is
a
map.
Well,
if
you
have
a
serialization
that
preserves
a
designated
ordering
in
your
map,
then
you
can
use
it.
If
seaboard
does
not
provide
that,
then
then
you
implement
it
so
that
it
does.
B
K
K
That
it's
ordered
right
and
so
I
said
that
map
versus
array
doesn't
impact.
The
information
model
I,
ordered
versus
unordered,
could
be
said
in
the
information
model.
If
we
said
it
had
to
be
ordered
than
the
information
while
it
could
say
that
if
it
had
a
reason
why
independent
of
any
serialization
format
or
any
data
format,
if
it
needed
to
be
ordered,
it
could
say
that
and
I
saw
some
discussion
that
I
heard
people
arguing.
Yes,
it
should
be
ordered,
was
what
I
heard
I.
K
B
A
K
U
This
is
thank
you
can
any
of
you.
If
you
really
really
invested
in
having
an
ordered
map,
you
could,
in
theory,
register
SIBO
check
for
that.
The
once
was
a
effort
that
have
an
implant
to
introduce
a
super
check
for
a
ordered,
multi
map
that,
even
though
the
members
won't
in
unique,
this
is
of
course
not
necessary,
but.
U
I
U
Although
moti
maps
have
other
issues,
so
there's
a
benefit
to
it.
This
is
the
desert,
but
there
are
also
very
messy
with
respect
to
consistency
and
redundancy
and
an
infinite
I
mean
there's
a
reason
by
didn't.
Do
it
and
there's
a
reason,
but
I
see
what
still
doesn't
do
it
and
people
abandon
the
idea.
K
N
O
S
N
Wanted
to
point
out,
I
I
think
there's
probably
two
reasons
for
constraining
order.
One
is
serialization
or
signatures
which
I'm
not
sure
is
actually
important
for
this
case,
since
you're
always
signing
a
specific
manifest.
Not
it's
not
a
signature
on
something
someone
else
will
be
generating,
but
the
other
reason
was
the
argument
of
making
poll
parsing
easier,
that
if
somebody,
if
the
ordering
is
specified
correctly,
the
processing
can
always
be
done
in
order.
N
One
thing:
I
wanted
to
point
out:
I
brought
up
on
the
mailing
list,
just
to
make
sure
we
consider
that
these
processing
steps
may
have
different
actors
that
will
do
subsets
of
them.
I,
don't
know
if
we
want
those
as
separate
processing
blocks
or
how
exactly
we
want
to
do
that
or
if
that's
addressed.
I
That
each
successive
actor
would
define
a
new
process
tree
which
would
define
what
the
recipient
of
that
process
tree
needed
to
do,
and
if
the
recipient
is
another
partial
processor,
they'll
have
to
again
define
their
own
manifest.
That
does
the
same
thing
again.
This
can
get
pathological.
Of
course,
if
these
are
all
signed,
but
I
guess,
the
question
is:
how
plausible
is
it
that
we
get
multiple
levels
deep
in
that
kind
of
a
kid
yeah
I
envision?
Maybe
two
not.
N
I
K
I
I
I
Resources
were
separated
from
assets
that
so
resources
the
thing
before
it's
installed
and
an
asset
is
the
thing.
After
its
installed.
We
can
work
on
the
terminology
if
you
don't
like
that,
I'm
not
tied
to
it.
I
description
of
the
installation
process
goes
into
the
manifest
conditions
were
divided
into
preconditions
and
postconditions.
I
So
I
this
is
pretty
clear
that
they're
still
ongoing
development.
This
is
still
a
work
in
progress
next
slide.
Please
so
separable
text
text
is
for
humans.
It's
not
used
by
devices
to
make
decisions,
or
at
least
that
is
the
guiding
principle
of
the
separable
text
concept.
If
there
is
some
kind
of
text
that's
needed
both
by
humans
and
devices,
this
proposal
would
mean
that
you'd
need
to
duplicate
it.
So
devices
typically
don't
need
to
receive
text.
These
are
IOT
devices,
but
it's
still
needed
in
management
systems.
I
Next
slide,
please
so
the
way
to
deal
with
that
is
that
we
divide
it
into
two
pieces.
First,
there
is
the
authenticated
manifest,
which
is
the
container
that
has
both
a
an
authentication,
a
Cosi
authentication
block
in
it,
its
signature
or
Mac,
and
a
seaboard
text
map
now
inside
that
text
map.
There
is
the
map
of
keys
to
strings
next
slide.
Please
David.
K
N
A
Dave
Walter
Meyer
as
an
individual
I'm,
an
author
of
another
draft
in
in
sack
I'm
around
Coast
web,
which
I
think
we
briefly
talked
about
and
some
earlier
working
group
meetings
and
that's
a
draft.
That's
actually
really
targeted
towards
management
systems,
and
you
know
providing
a
lot
of
the
human
text
that
might
be
used
in
in
those
management
systems.
Perhaps
we
might
want
to
investigate
how
we
could
use
curse
wit
to
provide
some
of
these
more
human
focused
capabilities,
leaving
our
work
around
manifest
to
be
more
Machine
oriented
would
sounds.
U
Hi
this
is
Hank.
Also
a
this
came
up
a
author
of
the
concise
off
identify
a
draft.
We
have
had
a
resource
collection
edit
that
was
dealing
with
describing
defining
filter
for
one
a
half
year
now
and
we
decided
to
detach
that
resource
extension
and
Saturday
to
suit,
because
it's
not
suitable
to
have
that
firmer
stuff
here,
I
think
and
I
did
that
tonight.
U
So
it
was
a
very
short
notice
that
didn't
bring
us
up,
basically
know
what
whatever
we
had
read
it
before,
not
maybe
at
the
intro
and-
and
this
is
based
on
maps
basically
and
know
now.
I
didn't
see
this
turning
of
events
that
this
would
be
a
norm
actually
saving
maps.
So
that's
great,
maybe
have
a
look
at
it.
Maybe
we
can
find
some
compromises,
its
merging.
D
And
the
Sunnis
I
was
wondering
that
Hank
yeah
the
question
to
you
like
you,
you
a
cause
of
the
of
the
information
model
document.
So
it's
a
feels
a
little
bit
strange
when
you
suddenly
overnight
work
on
some
stuff
and
put
it
out
and
then
say:
oh
maybe
we
should
cooperate
when
you
actually
the
cohorts.
U
Yeah,
that's
my
my
problem
was
I.
Was
such
a
strong
disconnected
in
the
data
model
and
things
Brendan
just
explained:
I
couldn't
just
use
the
information
model,
and
also
there
was
a
need
to
do
this
for
second
because
were
second
on
Friday
and
we
want
to
move
on
with
Co
switch
and
the
fire
of
hiware
the
shrim,
where
stuff
really
was
basically
holding
us
back.
That
was
never
gone
through
the
last
call.
U
It's
just
in
this
context
and
I
think
I
indicated
this
last
to
suit
sessions
also
redundantly,
but
this
should
not
be
a
surprise
that
that
we
were
cutting
that
out
and
bringing
that
here,
because
I
think
I
advertised
that
ready
last
year,
I
hope
everybody
I'm
all
about
that.
If
not
I'm.
Very
sorry,.
I
So
inside
the
authenticated
container,
so
that's
inside
the
manifest
itself.
The
text
is
authenticated
with
a
digest
or
potentially,
the
Coast
Whitlock
is
identified
with
the
died
with
a
digest,
and
that
is
about
all.
There
is
to
it
for
several
texts
on
to
multiple
payloads,
so
payloads
have
three
components:
a
resource
identifier,
which
is
to
say
exactly
where
to
find
the
thing
installation
instructions
and
with
that
can
include
cryptographic
info
when
it
comes
to
decryption
and
the
asset
description,
which
is
the
the
size,
the
location
to
store
it
and
the
digest
of
the
asset.
So.
Q
I
We've
done
here
is
split
payloads
out
into
multiple
parts
and
at
the
same
time
allowed
for
multiple
payloads
to
be
used.
We
needed
a
an
extension
to
this
concept,
specifically
for
Delta
and
other
advanced
use
cases,
and
what
that
did
was
it
turned
a
leonis
dependencies
and
payloads
all
into
resource
references
which
makes
things
a
little
bit
easier.
I
Assets
are
now
separate
from
their
resource
identifiers
so
that
they
can
be
overridden
independent
manifests
and
installation
instructions
are
separate
as
well,
so
the
resources
were
separated
from
assets
which
makes
all
resource
temperate
references
effectively.
The
same,
there's
no
need
to
distinguish
between
an
alias
to
dependency
or
a
payload
resources,
define
a
local
or
a
remote
input,
either
a
URI
or
a
diet.
Sorry,
a
the
local
or
remote
input
in
the
form
of
a
URI
and
a
digest
assets
define
an
installed
image,
which
is
the
size,
the
digest
in
the
location.
I
So,
due
to
some
discussions
on
the
mailing
list,
particularly
with
Frank
and
avi
and
sorry
if
I
pronounced
that
wrong
from
Nordic,
they
in
particular
there's
they
had
a
requirement
to
be
able
to
check
some
conditions
after
installation.
Now,
specifically,
that
was
some
kind
of
digest
or
a
custom
condition
of
which
we
haven't
elaborated
on
yet
I'm,
not
sure
quite
what
goes
in
there,
as
some
obviously
need
to
be
checked
before
installation.
G
I
There
were
two
choices
here:
we
could
make
two
lists
of
of
conditions,
or
we
can
duplicate
condition,
identifiers
to
specify
the
summer
preconditions
and
summer
post
conditions.
It
seems
like
separating
it
into
two
lists
is
the
right
choice
because,
again
in
as
with
the
pull
parser
concept,
it
makes
it
quite
clear
for
the
device
exactly
what
it
should
be
doing
at
any
given
time
and
with
the
duplicate
condition
identifiers.
That
would
not
be
the
case.
The
device
would
have
to
process
that
list
multiple
times
and
the
cost
for
making
two
lists
is
not
high.
I
Next
slide,
please,
the
component
identifier
ad
has
replaced
the
storage
identifier,
the
storage
identifier
was.
It
would
not
necessarily
adequate
for
all
use
cases,
so
devices
can
be
aggregates
with
more
than
one
processor,
with
two
or
more
different
storage
systems
and
the
component
identifier
allows
for
designating
which
storage
system
you're
on
on
top
of
that
storage
systems
and
hardware
components
can
be
nested,
so
it
seems
like
the
component.
I
Q
I
S
T
K
A
Okay,
so
so
today
we
talked
quite
a
bit
about
a
number
of
some
changes
to
the
architecture
that
need
to
be
done,
but
mostly
changes
to
the
information
model
and
and
manifests
so
I
think
it
would
make
sense
to
talk
briefly
about
when
we
could
expect
those
updates
to
be
completed.
So,
let's
start
with
the
architecture,
when
do
you
think
you
can
have
an
updated
architecture
posted
with
the
changes
discussed
next
week?
That
would
be
great
and
then
information
model.
A
M
G
G
D
A
So
yeah
data
model,
so
we
talked
about
some
of
the
changes
that
need
to
be
done
on
the
data
model.
Hank
you
also
posted
a
data
model,
so
I
would
encourage
the
authors
of
both
drafts
to
get
together
and
to
try
to
sync
up
on
on
the
differences
that
may
exist
between
between
the
two
I'm.
Are
you
willing
to
do
that.
C
U
The
driver
was
that
announcing
this
over
and
over
again,
we
are
now
in
the
state
that
we
are,
will
drive,
go
straight
through
working
group
last
call
and
we
had
to
cut
that
out
and
before
I
cut
it
out.
I
made
it
cementec
equivalent
to
the
current
submitted
data
model
so
that
there
is
no
confusion
there.
Why
is
this
differently
named
and
that's
what
recognize
everything
it's
just
all
written
in
maps
now
and
it's
not
in
the
coast
with
a
core
draft
anymore.
I
D
U
Actually,
we
had
a
map
structure
for
firmware
in
close,
but
for
over
18
months
and
we
started
to
align
more
that
it
suit
suit
formed,
and
we
saw
all
those
what
firm
word
that
we
should
maybe
wait
for
them
and
then
the
data
you
did
manifest
the
data
map
format
and-
and
this
all
took
a
lot
of
time,
so
we
aligned
with
that
but
we'd,
never
aligned
with
the
information
model,
is
very
new.
U
We
always
aligned
with
the
data
model
because
it
was
very
easy
to
align
with
it
was
very
specific
and
also
in
sea
war,
SPRs
the
coast
weights,
so
that
that's
why
I
did
not
use
the
information
model
to
allowed
to
create
the
update
the
I'm
from
extension,
but
I
used
the
current
data
model
because
would
be
easier
for
people
to
compare
them.
Yeah
the.
D
Current
data
model
that
print
percentage
is
brand
new,
it's
like
was
published
in
2nd
of
July,
and
so
it
and
that's
a
that's
what
he
presented
back
then.
Now
with
this
in
Mumbai,
we
made
already
some
changes,
so
I,
don't
I,
don't
see
like
if
there.
If
the
contribution
is,
should
we
use
maps
instead
of
arrays
and
that's
justifies
the
publication
of
the
document.
That's
fine,
but
I,
don't
understand
the
relationship,
then,
to
end
the
working
class
called
before
cosby'd
and
so
on.
D
If
it
will
most
likely
change
again
as
we
are
getting
the
feedback
from
the
guys.
The
difficulty
is
in
this
is
not
the
decision
about
area
or
maps.
I
think
that
the
more
time
went
into
discussing
on
how
the
whole
structure
looks
in
the
first
place,
because
different
people
had
different
use
cases
and
trying
to
encapsulate
all
of
those
was
sort
of
complicated.
U
Yeah,
that's
why
I
used
a
very
fresh
one.
That's
been
right
now,
all
right
now
and
it
did
the
difference
between
the
manifest
that
is
there
and
not
become
an
episode.
Think
and
the
one
that
I
submitted
is
that
the
one
is
tailored
to
be
a
resource
extensions
to
concise
software
identifiers.
So
they
are
embedded
in
software
I'd,
its
width
and
coach
weights
and
the
manifest
cannot
be
just
embedded
in
crosswords
and,
as
I
think,
someone's
highlighted
before.
U
There's
a
lot
of
benefit
to
use
cause
weights,
because
there
is
this
texture
representation
for
humans
already,
there
can
be
detached
from
the
other
stuff
and-
and
there
are
other
semantics
like
like
the
supersedeas,
patches
or
absolutes.
Other
things
is
also
already
there
and
entities
and
and
I
mean
everything
about
software
is
already
defined.
And
then
we
don't
have
to
reinvent.
D
The
difficulty
with
this
working
in
in
the
working
group
I
believe
is
well.
I
will
ultimately
be
to
get
those
companies
who
then
need
to
make
the
changes
to
their
code
in
the
discussions.
That's
that
that's
the
difficult
part
it's
whether
you
can
reuse
some
existing
snippet
of
a
few
text
lines.
It's
great,
it's
great!
If
you
can
even
use
those
data
structures,
but
that
will
not
make
the
difference
it
will.
It
will
make
a
difference
whether
Nordic
semiconductor
di
Infineon,
etc.
D
A
I'm
Dave
altmer
as
an
individual
contributor,
I,
think
I
think
the
desire
with
with
curse
word
is,
you
know,
there's
some
historic
work
in
this
space.
That's
been
done.
There
we'd
like
to
see
some
convergence
between
that
historic
work
and
the
work
that's
going
on
within
within
this
working
group.
So
you
know
to
some
extent.
Hanks
draft
is
a
starting
point
in
which
we
can
maybe
drive
some
of
that
convergence.
You
know
going
going
forward
and
I
believe
that
that
the
coast
would
draft
represents
a
good
path
forward.
A
As
far
as
representing
some
of
this
management
information
there's
some
adoption
of
a
closely
related
specification
in
the
industry
already
around
an
xml-based
format
which
curse
width
is
parallel
to
and
so
I
think
it's
worth
exploring,
whether
for
management
news
cases,
whether
that
the
coast
would
might
be
applicable
here,
I
think
we
could
arrange
a
presentation
for
the
virtual
interim
to
maybe
explore
how
how
Coast
wave
might
might
be
useful
to
decipher
those
those
use
cases.
If
there's
there's
interest
in
in
doing
that
and
I
think
Hank
is
interested
in.
A
U
I
think
that
Brendan
also
fixed
them,
but
they're
not
just
submitted
yet
so,
though
I
think
that's,
that's
not
an
issue
actually
sure.
At
least
that
is
my
impression.
So
now
the
thing
maps
are
in
there
because
coach
boots
are
basically
hierarchal
Maps.
So
that's
the
only
reason
why
they
are
I
use
maps
so
and
also
again,
I'm
surprised
that
this
is
a
surprise,
because
I
actually
really
reiterate
it
a
lot.
So
sorry
I've
ever
heard.
Please
don't
do
this
here
or
just
stop
with
that,
and
I
would
have
done
I'm.
A
Okay,
so
so
I
think
this
is
yes
chair,
head
back
on
so
I
think
we
have
some
issues
to
discuss
relating
to
the
to
the
manifest
will
be
helpful
to
get
an
update
of
that
draft
out
and
I'm
in
early
September
and
I
think
we
can
talk
through
I'm.
More
of
these
issues
during
during
the
virtual
interim.
A
A
We
also
have
taken
an
action.
We
need
to
add
the
information
model
to
as
a
milestone,
so
we'll
work
with
the
ATS
to
get
that
milestone
approved.
Is
it
the
arc?
I'm?
Sorry,
it's
the
architecture.
Yes,
any
other
actions
that
okay!
So
so
with
that
any
any
other
comments
we
can,
we
can
do
open
mic
for
a
little
while
if
there
aren't
any
other
comments
or
questions.
A
Question
yeah
sorry.
G
D
A
A
A
D
D
Yeah
and
also
maybe
we
should
a
remote
participation
that
works
pretty
nicely
last
time
at
the
Berlin
hackathon
I
was
surprised
how
many
people
were
remote
if
you're
interested
in
remotely
participating.