►
From YouTube: IETF109-SUIT-20201120-0730
Description
SUIT meeting session at IETF109
2020/11/20 0730
https://datatracker.ietf.org/meeting/109/proceedings/
A
A
I
would
like
to
sign
them
up,
but
they're
a
little
bit
lazy
at
the
moment.
A
Looks
like
we're
at
the
appropriate
time.
Maybe
we
should
get
started.
C
D
C
The
this
is
the
suit
working
group
at
itf
109
next
slide
by
by
this
point
of
the
week.
You
should
probably
have
seen
notewell
many
times,
please,
if
you're
going
to
contribute
in
any
way,
make
sure
you're
aware
of
these
rights,
privileges
and
responsibilities.
E
I
can
I
can
take
some
notes.
C
D
C
Okay
can.
C
The
the
slide
after
note,
well,
please
all
right
good.
C
No,
I
think
we
just
sorted
that
next,
one
okay,
so
this
is
the
agenda
for
today
we
basically
have
two
documents
that
are
out
of
the
working
group,
and
so
we
have
them
on
the
agenda
just
to
discuss
any
issues
that
are
raised
either
by
the
isg
or
the
ietf.
Last
call,
then
we'll
turn
to
the
suit
manifest.
C
We
have
a
few
open
issues
and
the
the
goal
is
to
get
that
ready
for
working
group
last
call,
and
then
we
have
two
non-working
group
documents
that
we
will
get
to
if,
if
time
allows
with
the
goal
of
seeing
if
they're
ready
for
work
and
group
adoption
next
slide,
please-
and
this
is
the
milestones
for
the
work
group
we're
behind
on
the
manifest
document
that
should
have
been
done
in
march
2020.
C
Obviously,
the
world
has
changed
since
march
2020,
but
we
will
hopefully
be
able
to
sort
out
a
great
deal
of
that
today.
I
think
that's
so
the
the
question
is
any
agenda
of
ashes.
C
Okay,
hearing
none,
so
the
first
thing
we're
going
to
talk
about
is
the
architecture
document.
I
think
I
think
dave
is
going
to
lead.
That
is
that
right.
D
C
Okay,
are
you
gonna
share
or
is
dave
gonna
run?
It.
D
B
Yeah,
no,
it's
nothing's
changed
since
then.
Okay
go
for
it
right,
so
suit
architecture
has
gone
through
iesg
evaluation
and
mostly
we've
got
just
a
relatively
few
number
of
comments.
The
the
ballot
positions
have
all
been.
No
objection,
typically,
no
objection
with
comment.
Mostly.
This
is
a
question
surrounding
questions
around
the
clarity
of
what's
required
in
the
architecture
versus
what
is
a
requirement
of
the
serialization.
B
B
If
we're
not
careful
here,
we're
going
to
make
quite
a
big
cluster,
so
I
guess
the
question
I've
got
is
whether
any
of
these
documents
are
actually
normative
to
the
content
of
the
suit
architecture
or
whether
all
of
these
documents
should
be
left
as
informational,
or
to
be
more
specific,
as
forward
references
for
places
that
the
content
of
the
architecture
becomes.
B
Relevant,
so
that's
really
the
summary.
I
I
personally
think
that
what
we
should
do
is
leave
the
references
as
informational.
I
don't
think
any
of
these
are
actually
normative
to
the
content
of
the
architecture
itself.
C
This
is
russ,
I
agree
as
well
the
only
one
that
I
question
is
the
rats
architecture,
but
I
I
think
it
I
think
it
informative
is
fine,
it'll,
be
an
information.
All
the
architecture,
documents,
suit,
teep
and
rats
will
all
be
informational,
so
an
informational
reference
should.
D
Be
fine,
so
my
rationale
for
even
the
rats
architecture-
I
so
teep
depends
on
suit
and
rats,
but
I
don't
believe
that
rats,
the
the
suit
depends
on
teep.
It's
the
only
other
direction
and
I
don't
believe
that
suit
depends
on
rats
either
right,
it's
just
indirect,
by
t,
depending
on
both
of
them,
for
example.
So
I
don't
think
there's
anything
that
you
wouldn't
refer
to
for
would
refer
to
rats
in
a
normative
fashion
for
us.
So
I
think
that
they're
all
informative.
C
Seems
fine,
so
let's
proceed
that
way:
I'm
not
hearing
anybody
or
not
seeing
anybody
in
jabber,
I
think
otherwise,
and
no
one's
in
queue.
So
I
think
that's
what
we
have.
D
E
I
had
maybe
this
is
hannah's.
Maybe
you've
seen
I've
just
provided
a
couple
of
pull
requests
in
response
to
the
isg
reviews
in
in
order
to
address
some
of
the
editorial
changes.
I
think
they
are
pretty
straightforward.
Don't
need
any
discussion
I
just
want
to
let
you
know
that
I
acted
on.
E
B
Okay,
so
the
suit
information
model,
as
far
as
I'm
aware,
has
actually
just
exited
isc
iesg
last
call-
I
saw
an
email
about
last-
call
expired
and
started
seeing
some
commentary
come
in
afterwards.
So
that's
my
understanding
of
where
it
is.
B
We
have
only
received
two
reviews
so
far,
gen
art
said
absolutely
nothing.
Other
than
looks
fine
sector
says
not
ready.
I
think
that
this
is
really
a
contextual
issue.
More
than
anything
else
and
the
reviewer
from
sector
essentially
said
that
he
didn't
look
like
an
information
model
to
him
and
well
fair
enough.
It's
not
it's
an
information
model
and
a
threat
model,
and
I
asked
if
we
changed
the
name
to
that.
B
Sounds
good
to
me:
okay
works
for
me
too.
He
also
drew
out
that
the
order
of
the
sections
is
slightly
confusing.
Now,
of
course,
what's
happened
here
is
that
we
originally
had
threats
and
user
stories
followed
by
requirements
followed
by
elements,
but
then
there
was
the
the
point
that
the
content
that
the
majority
of
people
will
be
looking
for
is
the
element
of
the
manifest,
which
should
then
be
at
the
front.
B
But
we
didn't
then
put
the
requirements
after
the
threats
and
user
stories,
which
means
that
there's
a
kind
of
a
zigzag
in
the
story
of
the
document
as
you
go
through
it
and
that
was
considered
confusing.
So
should
we
reorder
the
sections
to
go
elements,
requirements
and
then
threats
and
user
stories.
F
Hi,
oh
hi
brenton,
so
personally,
I
think
whatever
order
you
choose,
it's
the
wrong
one.
So
that's
first.
I
think
this
is
a
of
course.
So,
but
this
is,
I
think
that
is
correct.
This
is
about
people
want
to
understand
and
implement
this.
So
I
see
the
point
ietf
elements
first,
although
of
course
that
is
a
wrong
order.
F
If
you
inherit
this
wrong
order,
you
should
inverse
it,
and
that
is
elements
requires
threats.
You
could
alleviate
this
problem
by
naming
it
threaten
information
model
and
then
use
the
correct
order.
D
Yeah,
my
personal
preference-
and
I
agree
that
it's
a
matter
of
maybe
it's
preference,
but
I
like
the
order
that
things
are
in
right
now,
which
gives
because
when
we
first
put
the
things
in
that
order,
I
found
that
it
gave
a
natural
flow
right.
That
says:
here's
the
the
things
we're
trying
to
accomplish,
which
then
these
leads
to
these
requirements,
which
then
leads
to
these
solutions.
So
I
thought
that
was
a
fairly
logical
flow.
D
So
hank
said
one
thing
I
was
going
to
say,
which
is:
maybe
the
name
of
the
document
should
be
threat,
model
and
information
model
so
that
it
matches
stuff
and
then
I
might
have
the
table
of
contents
be
organized
such
as
a
section
inside
the
document
that
is
called
threat
model
and
then
a
section
is
called
information
model
after
that.
Okay,
and
so
that
means
that
the
title
would
be
threat
model
information
model.
The
table
of
contents
would
be
structured
like
threat
model
and
then
after
that
would
be
the
information
model
section.
D
And
then
the
elements
are
in
the
information
model,
section
right,
and
so,
if
you
only
care
about
that,
you
jump
to
the
information
model
section,
but
I
think
that
would
be
less
work
than
trying
to
reflow
the
texts
to
make.
You
know
backwards,
reference
stitches
to
terms
and
things
like
that
you
have
to
fix
up,
and
so
I,
like.
B
D
B
Make
them
all
of
the
references
are
symbolic,
so
reflowing,
it's
trivial.
D
Yeah
so
anyway,
I
like
the
order
that
it
is
right
now,
but
I
would
change
the
title
and
the
table
of
contents.
You
know
section
ordering
section
labels,
I
should
say
to
match
the
direct
model
information
terms,
but
it's
just
a
matter
of
preference
right.
So.
B
D
Okay,
that's
the
one
that
I
remembered
in
my
head,
which
that
order
is
the
one
that
I
was
saying
that
made
sense
to
me
when
I
first
read
that
version
of
the
document
is
that.
E
E
So
what
is
what
is
the
proposal
from
hank
threats
and
then
requirements
elements
or
which
order?
I
just
for
the
meeting
minutes.
F
So
this
is
the
thing
again
in
the
minutes.
Yes,
the
the
the
the
story
that
brent
was
talking
about
is
threats,
then
deriving
requirements
from
threats
and
then
certifying
them
for
the
elements
and
that
that
is
the
story.
Yes,.
D
B
Yeah,
I'm
as
in
the
manifest
document,
having
a
how
to
use
this
document
is
probably
a
good
thing.
B
Yep
all
right,
then
there
were
a
couple
of
nits
on
the
the
use
of
required
versus
optional
as
applying
to
serialization.
B
So
essentially,
what's
going
on
here
is
that
the
information
model
is
saying
that
a
the
support
for
a
particular
information
element
must
exist
in
a
in
any
given
serialization
format,
but
that
it
is
optional
to
use
in
any
given
manifest.
So
you
have
a
strange
completion
of
required
and
optional
in
the
same
element,
and
there
were
a
couple
of
places
that
that
cropped
up
and
the
reviewer
felt
that
it
would
be
helpful
to
clarify
exactly
what
was
required
and
what
was
optional.
B
So
I
think
that
one's
relatively
straightforward,
the
only
other
thing
that
came
up
really
in
the
review,
was
a
question
about
whether
there
is
some
canonical
source
of
a
reference
to
the
stride,
threat,
modeling
methodology
and
that
the
one
that
we
currently
have
in
there
may
not
be
sufficiently
canonical
and
might
cease
to
exist
at
some
point
in
the
future.
B
Are
pointing
to
a
microsoft
source,
I
I
don't
know
if
it
is,
you
know,
if
there's
any
guarantee
that
it
will
continue
to
live
where
it
currently
is
the
hold
on
I'm
just
loading,
the
the
exact
location.
D
B
So
the
one
that
we're
pointing
to
just
sorry
one.
B
Moment
is
we're
pointing
to
one
that
is
coming
from
msdn,
so
I
don't
know
if
we're
gonna
get
any
more
canonical
than
that
right.
D
In
somebody's
book
that's
been
published
or
something
like
that,
but
the
msdn
might
be
the
best
online
reference
that
exists
but,
like
I
said,
I
suspect
it's
showing
up
in
one
or
more
physical
publications.
B
D
If
it
would
have
helped
so
microsoft
has
the
ability
to
create
short
links
like
aka
dot,
ms
slash
whatever
the
well.
Maybe
it's
called
an
fw
link.
So
there's
a
number
of
things
that
when
microsoft
publishes
references
to
its
own
msdn
things,
it
uses
something
that
it
can
redirect
if
msdn
ever
changes
that
structure.
So
if
it
would
help.
E
D
Can
find
out
if
there
is
one,
if
not,
I
can
get
one
created.
That
is
a
stable
link
that,
even
if
the
structure
changes,
the
link
itself
would
still
be,
it
would
be
still
would
still
be
stable.
B
I
think
that
would
be
helpful
unless
there's
some
relatively
canonical
reference
outside
of
microsoft,
that's
likely
to
be
more
stable.
I
I
don't
know
what
the
right
answer
is
here,
so
I
I
defer
to
people
with
more
experience
in
these
references.
D
D
Okay,
so
hannah's
put
that
in
the
minutes
that
I
have
an
action
item
unless
somebody
else
beats
me
to
it
with
a
better
reference.
A
Thread
modeling
book
the
wiley
book
by
showstack
that
talks
about
stride.
We
could
maybe
point
to
that.
G
I
might
have
missed
my
window,
but
I
was
just
curious
dave
we're
when
you
talk
about
this
and
open
information
model.
Where
were
you
specifying?
This
would
be
set
up
and
specified.
G
I'm
sorry
david.
The
questions
for
you
question
was
when
you
said
what
we're
going
to
define
this
in
the
standard
data
model.
Where
is
this
defined,
and
where
can
I
download
the
schema
to
understand
it?.
D
In
that
sense,
the
data
model
is
the
document
that
we're
showing
on
the
screen
right
now
that
we're
about
to
talk
about
the
suit
manifest
in
that
section.
Oh.
G
B
Well,
actually
in,
I
hope
that
it's
not
going
to
be
that
complicated,
but
it
yeah.
B
B
Right
shall
we
so
we
started
yeah
okay,
so
there
are
a
few
technical
changes,
but
they
are
relatively
minor,
there's
only
one
that
might
be
considered
breaking
and
that
is
separating
the
digest
out
from
cozy
sign
and
cozy
mac.
Previously,
that
was
the
payload
of
the
cozy
object
or
cozy
structure.
I
mean
the
rest
of
these
are
additions
and
they
are
hopefully
relatively
straightforward.
B
So,
let's
move
on
next
slide,
please
yeah.
There
we
go
so
first
off
private
enterprise
number.
There
was
some
discussion
in
ietf
108
about
using
private
enterprise
numbers
rather
than
the
uuid
based
vendor
ids.
So
what
I've
done
is
looked
at
what
options
we
have
for
encoding,
a
private
enterprise
number
now,
since
private
enterprise
numbers
are
actually
oids
that
are
relative
to
the
the
ietf
private
enterprise
number
oid,
it
seemed
like
the
best
thing
to
do
was
retain
those
semantics.
B
So
since
ietf
seaboard
tags,
oid
has
cropped
up,
it
seemed
like
this
being
an
a
c
board
document
having
a
seabor
representation
of
an
oid
was
probably
the
right
answer,
especially
given
that
we
have
a
a
tag
for
a
relative
oid.
B
Now,
what
I've
done
is
I've
gone
one
step
further
than
that,
and
I
have
asked
the
authors
of
that
draft
to
also
include
a
specific
tag
for
a
pen.
So
what
that
is
is
semantics
that
are
almost
identical
to
the
relative
oid,
but
because
they
are
understood
to
be
relative
to
the
private
enterprise
number
oid.
They
actually
resolve
to
a
full
oid,
because
we
already
know
what
that
prefix
is
so
now
we
have
a
way
to
encode,
not
just
the
numeric
pen,
but
the
any
sub-assignments
that
might
show
up
as
well.
B
B
This
has
some
ramifications
for
class
id,
so
the
way
that
class
id
was
supposed
to
be
constructed
was
to
use
the
uuid
version
of
the
vendor
id
as
a
uuid
namespace
and
then
derive
the
class
id
from
any
class
specific
information
and
that
uuid,
but
that's
not
going
to
work
if
the
vendor
id
isn't
a
uuid.
B
So
what
I've
done
is
provided
a
canonical
way
of
converting
a
as
a
pen
to
a
uuid
so
that
you
can
then
derive
a
class
id
from
it.
B
So
what
this
requires
is
the
the
pen
as
with
the
tag
all
of
that
as
the
cpor
pen
element
that's
listed
down
below,
and
it
requires
a
name
space
for
those
so
for
the
name
space
next
slide.
Please.
B
Next
slide,
please:
oh
there
we
are
yeah,
so
the
way
that
the
the
namespace
id
is
defined
is
by
going
through
and
constructing
a
namespace
id
from
the
existing
oid
namespace
using
the
seabor
oid
encoding
of
the
private
enterprise
number.
B
D
D
B
So
that
is
all
done
now.
Next
slide.
B
So
we
also
discussed
at
ietf
108
the
idea
of
removing
the
suit
digest
from
the
cozy
payload
and
making
it
the
first
element
in
the
the
suit
off
list
now.
The
reason
for
this
is
that
it
could
show
up
multiple
times
if
the
cozy
sign
one
or
cosy
mac.
Zero
objects
are
used
and
there's
more
than
one
signature.
B
B
What
this
does
mean
is
that
it
enforces
that
each
manifest
can
have
only
a
single
canonical
digest
with
a
single
choice
for
what
the
what
type
of
digest
it
is.
So
that
means
that
you
can't
refer
to
a
given
manifest
with
both
a
sha-256
and
a
that
would
be
invalid,
because
the
mana,
the
the
digest
that
shows
up
in
that
manifest,
would
be
one
or
the
other.
Not
both.
B
However,
what
it
does
mean
is
that
if
you
have
two
recipients
that
don't
support
the
same
digest,
parameters,
there's
no
way
to
send
an
identical
manifest
to
both
of
them.
I
think
that's
a
bit
of
a
corner
case.
I
don't
think
I'm
overly
worried
about
that
particular
problem.
So
I
think
this
is
probably
fine.
B
G
G
C
B
So
I
think
that's
the
that
that's
it
for
the
removal
of
suit
digest.
What
it
means
is
essentially
that
we're
using
the
cozy
authentication
structures
in
detached
mode
next
slide.
Please
I've
added
into
c
board
tags.
B
I
don't
know
if
these
are
the
right
values,
but
the
the
argument
I'll
make
is
that
suit
envelope
is
likely
to
show
up
on,
especially
in
constrained
connections,
far
more
often
than
suit
manifest
with,
as
as
a
bear
item
and
as
a
result,
I
think
that
we
should
preferentially
aim
for
a
smaller
value
on
envelope
than
on
manifest.
B
Now
that
said,
we
have
a
structure,
that's
usually
around
300
bytes,
including
signature.
So
quibbling
over
a
two
byte
tag,
I
think,
is
probably
unnecessary
and
I
would
be
happy
with
a
three
byte
tag,
so
we
could
probably
go
over
the
256
boundary
without
really
much
noticeable
cost
and
knowing
that
many
of
these
tags
are
in
short
supply.
I
I
don't
see
a
problem
with
that.
So
maybe
we
should
change
that
if,
if
anyone
has
a
particular
idea
on
on
what
tag
value,
we
should
look
for.
B
I
know
that
choosing
tags
that
resolve
to
ascii
characters
is
popular.
Then
perhaps
we
someone
has
a
suggestion.
B
Sure
sure
I'm
just
waiting
for
someone
to
pop
up
and
say
pick
this
one,
but
maybe
I'll
leave.
B
B
All
right:
well,
let's,
let's
move
on
in
any
case,
we've
also
added
index
lists.
Now
this
is
just
an
extension
of
the
original
index
equals
true
semantics.
So
the
idea
being
that
when
index,
when
the
the
in
either
the
dependency
index
or
the
component
index
was
set
to
true,
then
it
would
apply
to
all
components
or
dependencies
respectively
or
each
each
individual
command
would
reply
would
apply
like
that.
So
this
adds
a
new
semantic
which
says
that
you
can
provide
a
list
of
indices
to
which
all
subsequent
commands
apply.
B
So
if
you
have
two
components
that
need
to
be
loaded
into
ram,
you
want
to
be
able
to
say
load
my
two
components
into
ram,
not
load
component,
a
load
component
b
and
the
difficulty
with
the
index
equals
true
semantics
is
that
the
destinations
of
those
loads
would
not
themselves
be
loadable
and
the
commands
would
not
apply
to
them.
So
what
this
does
is
gives
you
the
opportunity
to
say
load
component,
one
load
component,
two,
but
don't
load
three
and
four,
because
that's
where
the
loads
are
gonna
wind
up.
B
This
required
a
little
bit
of
thinking
through
what
it
means
for
the
try,
each
and
run
sequence
commands
and,
and
what
that
essentially
means
is
that
we
had
to
properly
document
exactly
what
the
semantics
are.
When
you
use
one
of
these
multi-component
indices
on
one
of
those
command
sequences
and
what
what
it
means
is
that
they
shouldn't
actually
know
that
that's
what's
going
on
the
content
of
the
command
should
not
be
aware
of
this.
B
Instead,
the
command
as
a
whole
should
be
run
once
with
each
possible
index,
regardless
of
whether
that's
the
index
equals
true
semantics
or
the
index
equals
list
semantics,
they
should
only
ever
get
the
numeric
indices,
so
that's
now
been
clearly
defined
in
the
document,
which
should
lead
to
less
implementation
errors.
I
hope
next
slide.
Please.
B
And
we
have
removed
suit
report
and
it's
been
factored
into
its
own
draft,
which
I
think
we're
coming
to
very
shortly,
so
that
was
just
yeah.
Okay,
fine,
all
I
was
gonna
say
was
that
it
didn't
have
a
lot
of
bearing
on
the
content
of
the
suit
manifest
itself
and,
and
so
it
needed
to
be
in
its
own
draft.
B
Dave
thaler
gave
us
a
really
substantial
review,
which
I
don't
know
how
much
time
you
spent
on
it,
but
I
tell
you
going
through
it
and
putting
those
changes
in
sure
took
me
a
while
that,
so
that
that's
that
was
good
review
and
I
think
that
the
document's
substantially
better
for
it.
One
of
my
my
remaining
frustrations
with
this
document
is
that
it
is
enormous
and
it
this
is.
This
is
frustrating
because
it
is
a
relatively
simple
concept.
B
All
all
we're
defining
here
is
a
bytecode
interpreter
and
the
arguments
and
and
values
it
takes
or
essentially
something
of
that
effect.
But
the
the
net
effect
is
that
when
we
get
around
to
describing
all
of
this.
B
B
One
of
the
things
I've
done
to
try
and
aid
clarity
in
the
examples
is
remove
text
printing
of
byte
string,
wrapped
c
bore
so
now
there
isn't
an
enormous
quantity
of
just
hex
printed
noise
in
the
examples
anywhere
that
that
would
have
been
has
been
replaced
with
an
explicit
b
string,
dot
seaborg
as
a
as
a
reference
back
to
the
cddl
that
shows
the
decoded
sebor
inside
it
with
no
hex
printing
around
it
next
slide,
please,
I
think
that
might
be
the
end
of
it.
Is
that
the
end
yeah?
That's
the
end.
D
I
had
two
comments,
so
I
don't
know
if
there's
any
people
in
queue.
D
Okay,
then
I'll
go
ahead,
so
I
just
want
to
report
out
to
the
rest
of
the
working
group
that
there
was
a
first
that
there
was
a
topic
that
came
up
in
teep.
That
brennan
was
there
for,
and
just
wanted
to
summarize,
that
it
had
to
do
with
the
use
of
component
ids
and
there's
another
message
on
the
list
after
the
meeting
that
brandon
and
I
and
hannah
and
folks
are
in
and
the
remember,
teep
uses
suit
and
uses
rats.
D
D
The
question
was,
you
know
right
now,
as
as
in
that
meeting,
we
said
the
suit
manifest
uses,
a
component
id
which
is
basically
a
path
of
unique
identifiers
and
optionally.
You
can
also
use
the
coswood
in
the
rats
working
group
inside
the
evidence.
D
Should
we
have
just
one
of
those
as
mandatory
more
like
the
suit
manifest
does,
and
if
we
think
that
say
the
component
id
path
is
the
mandatory
one
and
coswood
is
optional,
then
it
might
behoove
the
rats
working
group
to
take
that
into
account
when
doing
eating
coding.
So
that
was
the
summary
of
that
issue.
Right.
B
Okay,
my
my
take
on
this
is
that
suit
needs
to
tell
the
manifest
processor
where
to
put
something
exactly.
B
E
B
E
D
D
Okay,
so
that
was
the
first
topic
and
the
second
topic
I
just
wanted
to
tee
up,
because
I
posted
it
to
the
list
hold
on
and.
F
Hank,
okay,
hi
hi:
this
is
hank.
Actually
I
want
to
talk
about
component
id,
so
there
is
a
draft.
F
Actually
I
don't
know
if
it's
expired,
but
it's
the
suit
claims
id
that
brent
and
I
aggregated,
and
there
is
a
system
property
claim
in
there
that
is
actually
component
id,
so
why
this
is
not
in
the
each
core
id.
We
most
certainly
assume
that
this
is
required.
F
If
you
want
to
express
this
in
evidence-
and
we
have
two
sets
of
claims
here-
that
can
be
used
in
evidence
or
even
at
the
station
results-
and
these
are
the
system,
property
claims
and
the
interpreter
record
claims,
and
so
I
am
under
the
impression
that
this
is
already
on
the
radar
due
to
basically
as
us
having
it
on
the
radar.
F
I
am
not
entirely
sure
it
has
if
it
has
to
go
into
the
car
each
draft
it
could,
but
it
would
a
little
bit
split
one
item
out
and
single
it
out,
and
that
was
a
little
bit
confusing
to
the
context.
Maybe
actually
I'm
not
really
worried
about
that.
We
can
reference
it
here,
instead
of
defining
it
here
same
same,
so
it's
on
the
radar.
I
don't
think
that
is
a
issue
actually.
D
I
think
it
stands
for
a
sensor,
markup
language.
I
think
it's
like
a
batch
of
values
that
the
way
of
expressing
a
batch
of
values
that
the
one
of
their
iot
working
groups
did.
Okay,.
D
D
I
thought
that
one
of
the
use
cases
was.
If
I
have
a
set
of
temperature
settings
each
taken
over.
You
know
10
second
period
over
the
last
hour,
then
I
can
express
them
all
in
a
sentimental
format
and
send
them
off
in
one
message.
That
type
of
thing,
I
think,
is
an
example
of
a
use
case
and
again
yeah.
I
agree
with
you.
I
don't
see
the
overlap
with
suits
so.
B
Okay,
so
so
far
the
the
chat
seems
to
be
agreeing
with
that.
Okay,
all
right
should
we.
D
Okay,
so
I'll
bring
this
up,
mainly
because
this
is
the
draft,
that's
overdue,
and
so
at
the
expense
of
stealing
a
couple
minutes
from
the
non-working
group
documents.
I
think
that's
the
right
call
is
because
we
want
to
be
done
with
this
one.
D
So
the
message
that
I
posted
to
the
list-
I
will
summarize
the
draft
right
now
talks
about
how
you
install
suit
manifest,
whether
that's
installing
a
component,
the
first
time
or
updating
an
existing
opponent
t
has
to
be
able
to
install,
update
and
delete
okay
right
now
the
draft
doesn't
say
anything
about
how
you
might
go
through
any
type
of
an
uninstall
procedure.
D
I
think
it
should,
because
I
would
like
something
I
could
just
reference
in
t,
because
I
can
imagine
multiple
possible
answers
and
we
should
just
pick
one
so,
for
example,
the
examples
that
I
put
in
there
do
you
say
in
order
to
delete
to
delete
a
component,
you
bump
the
manifest
version,
number
have
no
payload
and
put
commands
in
there
to
delete
it,
and
so
it's
another
manifest
version
of
the
same
component.
D
B
That's
that's
a
fair
comment.
That's
going
to
require
a
little
bit
of
of
thinking
through
so
just
to
to
explain
where
the
problem
lies
here.
Essentially,
the
the
issue
that
I
see
is
that
there's
a
dramatically
different
behavior,
depending
on
whether
you've
got
an
execute
in
place
or
or
raw
flash
type
device,
or
whether
you've
got
a
file
system
device
and
and
they
act
very
very
differently.
B
The
other
thing
is
that
you
might
not
actually
want
to
allow
a
particular
manifest
to
delete
a
payload
of
a
previous
version
of
itself,
because
that
would
that
would
open
the
door
to
a
number
of
reliability
problems.
So
so
that
seems
to
me,
like
the
the
tpu's
case,
is
actually
orthogonal
to
the
to
the
reliable
unattended
iot
device
use
case
and
that
we,
this
is
going
to
take
some
very
careful
handling
to
make
sure
that
we
don't
get
it
wrong.
D
Yeah,
I
think
that
the
use
case
can
come
up
any
time
that
you
can
have
multiple
independent
things
installed.
So
like
multiple
apps
installed,
for
example
right,
it
can
come
up
not
just
in
a
tp
use
case,
but
any
time
that
you
can
install
multiple
things
supposed
to
say
one
piece
of
firmware
that
you're
always
overriding.
You
have
to
have
a
piece
of
firmware
at
a
boot
right
anytime,.
D
Things
on
top
of
that,
this
problem
can
come
up
an
example
of
a
complexity
and
t.
That's
very
deep
specific
is
antique.
We
used
to
have
this
notion
of
security
domains
right,
and
we
said
well
that
was
pushed
down
to
the
suit
manifest
if
you
need
to
create
a
security
domain
at
the
time
that
you
add
a
an
app
that
would
depend
on
it.
Well,
what
about?
If
you
delete
that
app,
you
delete
the
security
domain
or
not,
and
you
might
imagine
that
you
want
that
to
be
configurable
somehow
and
so
exactly.
D
B
Yup,
I
see
the
I
see
the
challenge
there.
I
I
understand
the
use
case
I'll
I'll
have
to
I.
I
suspect
that
the
answer
is
that
much
like
we've
got
a
way
to
fetch
something
and
to
copy
something
we
need
an
explicit
delete.
I
suspect
that
that's
the
answer
and
there's
a
couple
of
reasons
that
that's
important,
but
the
thing
that
we
definitely
need
to
clarify
is
what
is
the
behavior
if
you
have
multiple
copies
of
something.
B
So
if
you've
got
multiple
different
copies
of
the
of
the
ta
and
you
say,
delete
it,
but
each
one
has
a
different
component
id
right,
because.
B
The
thing-
and
maybe
that's
true
in
the
teep
use
case,
but
that's
not
true
for
all
suit
devices.
It's
fine
for
me
to
say
the
tls
library
and
then
have
that
selected
based
on
which
one's
most
recent
and
valid
and
its
manifest
works.
And
then,
if
something
fails-
and
I
need
to
do
a
rollback-
I
pick
the
previous
tls
library
and
and
for
that
to
work
they
have
to
have
the
same
component
id.
So
that
becomes
a
challenge
when
I
now
say
delete
the
tls
library,
which
one
do
I
delete.
D
Well,
the
same
thing
comes
up.
I
should
say
that
in
teep,
when
the
tip
has
to
be
able
to
express
the
list
of
things
that
are
installed
and
right
now
in
the
discussion,
the
teep
we
said
we
want
to
do
that
by
component
id
now.
I
think
that
does
force
teeth
to
always
have
unique
ones
and
never
have
the
collisions
based
on
that.
D
Up,
I
did
post
it
to
the
list
yesterday,
but
most
people
haven't
seen
it,
but
I
my
belief
is,
unless
somebody
tells
me
otherwise
in
this
meeting.
My
belief
is,
we
don't
have
to
have
the
answer
right
now.
We
just
have
to
agree
that
the
answer
should
be
in
the
suit
manifest
document
before
we
ship
it
to
isg.
B
I
will
put
my
thoughts
down
in
an
answer
to
that
email
so
that
we
we
keep,
that
discussion
going
and-
and
hopefully
we
can
come
to
a
resolution
on
it
fairly
quickly.
Okay
sounds
good
thanks.
A
C
It
okay
to
the
suit
report.
I
saw
no
one
else
in
queue
and
I
didn't
see
anything
else
in
chat.
So
let's
go.
We
we
have
less
than
10
minutes.
B
B
So
what
you
need
to
know
to
be
able
to
work
out
exactly
what
your
manifest
processor
did
is
the
digest
of
the
root
manifest.
So
you've
got
something
to
refer
to
the
canonical
uri,
so
you
can
fetch
the
full
set
of
the
manifest,
regardless,
if
anything
of
whether
or
not
something's
been
stripped
on
the
end
node
the
and
then
for
each
condition.
Failure
you
need
to
know
which
manifest
it
was
processing
the
section
that
it
was
in
how
far
into
that
section
it
was
the
current
manifest.
B
B
There
are
a
couple
open
issues
with
this
now,
specifically
there's
the
the
question
as
to
what
happens
when
you've
got
strict
order
set
to
false
and
a
condition
fails.
That's
not
exactly
clear
at
the
moment
so
need
to
work
through
that
one
and
then
there's
a
question
of
whether
we
should
add
an
anti-replay
mechanism
to
it.
So
that's
really
it
and
I
believe
the
answer
to
the
anti-replay
mechanism
is
yes.
It
should
contain
some
kind
of
unique
number,
however,
that
works
whatever.
B
That
looks
like
probably
a
byte
string,
and
the
interrupt
question
is
or
is
still
difficult,
so
we'll
have
to
work
through
that
one.
There
you
are,
as
I
said,
short
document
short
number
of
slides.
D
Yeah,
so
I
believe
as
chairs
this
is
a
question
to
dave
and
russ.
Should
we
ask
for
a
call
for
adoption
at
this
point
as
a
data
point
for
the
working
group,
the
teep
working
group
in
the
past
version
of
the
suit
manifest
document
that
has
reports
in
it?
The
teat
protocol
took
a
dependency
on
the
suit
reports
and
referred
to
that,
and
since
it
was
split
out,
the
t
protocol
now
refers
to
this
document,
which
is
not
a
working
group
document.
D
C
I
have
no
objection.
Does
anyone
in
the
meeting
have
an
objection.
D
C
E
C
Support
in
in
chat
and
no
objection
so
we'll
do
that,
and
I
think
we
have
the
mud
document
next,
but
we
only
have
four
minutes.
I
don't
know
how
far
you
can
get
into
it.
B
So,
just
as
background
we've
already
talked
about
the
mud,
one
in
ietf
108,
so
there's
not
anything
new
to
report
on
it,
though
this
is
just
a
very
quick
overview,
and
hopefully
that
is
helpful.
So
the
idea
here
is
that
we
want
to
deliver
some
mud
info
and
suit,
and
to
do
that
we
need
some
new
data
in
suit
manifests
and
some
new
data
in
eat.
B
Next,
please,
the
the
changes
to
suit
would
mean
that
we
add
an
envelope
extension
and
specifically,
that
would
contain
a
mud,
container
and
we'd
need
to
add
a
manifest
extension
to
integrity,
protect
that
mud
container,
the
mud
container
itself
would
have
either
a
url
or
a.
B
B
B
Then
the
mud
manager
would
obtain
the
attestation
report
now,
I'm
assuming
that
that's
already
been
verified
and
it
acts
as
a
relying
party
in
this
case
the
it
would
then
retrieve
a
canonical,
manifest
and
validate
the
authenticity
of
that
manifest.
B
B
C
C
Less
than
a
minute
so
and
that's
I.
D
A
Right
right,
I
think
we
also
had
some
discussion
about
whether
we
would
need
to
recharter
in
order
to
add
this
work
item,
and
I
think
the
agreement
was
last
time
that
we
would.
C
Okay,
so
we
we
should
start
the
the
discussion
of
the
recharger
text
before
we
do
the
call
for
house
all
right
we're
out
of
time
so
go
get
your
virtual
cookies
and
we'll
see
you
at
in
the
last
session.
Maybe
I
hope
you've
enjoyed
this
virtual
itf.
A
A
D
So
dave
waltermile
you're
still
on
what
did
we
keep
sometime?
I'm
now
just
looking
at
the
chat
room
since
I
couldn't
do
that.
Well,
it's
in
the
screen
did
we
have
a
conclusion
on
the
stride
content
on
the
stride
reference
via
the
chat
discussion.
A
Well,
I
I
think
I'd
propose
that
we
reference
the
showstack
book
as
a
stable
reference.
D
D
A
I
have
a
copy
of
that
book,
but
it's
unfortunately
in
my
office-
and
I
don't
have
access
to
it-.
D
But
you're
sure
this
one
covers
stride
with
a
title
like
that
I
should
but
the
table
of
contents.
A
D
Yeah,
I
see
it
yeah,
I
think,
there's
multiple
possible
books.
This
one
looks
fine
to
me
if
this
is
one
that
people
are
familiar
with.
It's
a
wylie
and
a
dr
dobbs
jolt
award
finalist
sure
this
one
looks
like
a
fine
reference
to
me.
So
then
I
will
not
do
my
action
unless
somebody
tells
me
otherwise,
if
that's
going
to
be
our
default
answer,
so
I
mean
separately,
I
will
still
go
and
get
a
stable
link
for
it,
but
I
don't
think
we
need
to
use
it
in
the
suit
manifest
document.
B
I
I
will
take
what
what
makes
sense
and-
and
I
I
get
that
isbns
are
less
likely
to
change
than
urls.
D
Should
we
ask
on
the
list
whether
people
prefer
a
book
that
you
can
only
pay
for
or
whether
people
prefer
a
non-paid
source
yeah.
B
D
Think
there's
any
document
in
the
ietf
that
that's
referenceable
on
that.
So
maybe
there's
an
option
that
says
you
could
reference
both
the
book
and
the
microsoft
source,
which.
E
D
You
at
least
one
paid
guaranteed
stable
thing
and
one
free,
possibly
stable
reference
right,
so
you
can
do
both.
B
D
A
Well,
I
still
have
you
brandon:
could
you
draft
a
few
sentences
for
the
charter
text
on
or
at
least
to
propose
some
charter
text
for
the
the
suit
report
and
and
suit
mud.
D
My
interpretation
is
the,
and
so
I
don't
know
if
roman
is
still
on,
he
may
have
dropped
off.
I
think
he
was
on
here
earlier.
Let
me
check.
Yeah
roman
is
still
on
the
at
the
discussion
of
having
to
reach
harder.
D
D
No,
it's
just
a
sequencing
question.
Can
we
start
doing
the
call
for
adoption
and
the
recharter
discussion
in
parallel
or
do
we
need
to
serialize
them.
B
D
Okay,
so
it
only
matters
well,
not
only,
but
it
matters
to
the
teep
working
group,
because
they'll
have
a
normative
dependency
on
the
suit
report,
which
means
t
protocol
can't
go
to
rfc
any
sooner
than
the
suit
report
does
yeah,
and
if
it's
blocked
behind
a
recharger
effort,
then
that
adds
delays
in
the
suit
into
the
tea
protocol,
which
may
or
may
not
be
an
issue.
So
well.
This.