►
From YouTube: IETF108-SUIT-20200731-1100
Description
SUIT meeting session at IETF108
2020/07/31 1100
https://datatracker.ietf.org/meeting/108/proceedings/
A
So
dave
meat,
echo
just
reported
that
there's
no
hotkey,
so
you
do
have
to
sit
there
quietly.
B
C
Okay,
it
is
time
so,
let's
get
started,
the
recording
appears
to
be
on
given
the
button
at
the
bottom,
so
we're
gonna
start
the
session
and.
C
C
C
C
Thank
you.
Thank
you
very
much,
jim
okay.
So,
let's
turn
to
the
chair
introduction
slides
next
slide.
Please
dave!
C
This
is
the
note
well
by
friday.
You
should
all
be
very
familiar
with
it
by
now,
but
please
don't
speak
at
the
like.
If
you
haven't
checked
this
out
next.
C
So
this
is
the
agenda
that
we've
put
together
the.
C
C
C
See:
okay
next
slide:
this
is
just
an
update
of
where
we
are.
We
are
not
too
too
far
behind
about
three
months
on
the
last
milestone,
but
during
today's
discussion
we're
going
to
find
out
if
we're
going
to
be
a
lot
further
behind
or
not
depending
on
the
the
choice
we
make
going
forward
and
we'll
just
update
the
milestone
depending
on
that
update,
okay,
I
think
that's
it.
So,
let's
turn
back
back
one
slide
to
the
agenda.
Thank
you,
okay.
C
So
the
first
thing
we're
going
to
talk
about
is
the
hackathons
that
happened
and
I
think
brendan
posted
some
slides
about
that.
So
I'll
turn
it
over
to
brendan.
Thank.
C
G
Okay,
so
there
are
were
two
hackathons
that
happened
recently.
There
was
the
one
that
we
planned
on
the
list
for
july
13th,
coincidentally,
the
same
day
as
the
submission
deadline
for
ietf
108.
I
think
I'd
prefer
if
we
could
do
that
a
little
differently
next
time
and
then,
of
course,
there
was
the
ietf
hackathon
week
next
slide,
please.
G
So
there
are
a
few
I've.
I've
tried
my
best
to
merge
all
of
the
different
plans
that
I
heard
of
for
both
of
these
hackathons,
and
I
I
think
I've
got
most
of
them.
If
I
left
you
out,
I'm
very
sorry,
I
I
it
was
not
intentional,
so
we
did
make
some
good
progress
I'll
get
to
that
in
a
moment.
Yeah
there
were
quite
a
wide
variety
of
people
participating
in
this,
which
I
was
quite
pleased
to
see.
G
So
I
guess,
let's
get
on
to
the
progress,
so
I've
added
dependency
support
to
the
manifest
generator
example,
and
hopefully
that
will
make
its
way
into
an
example
that
is
usable
in
the
in
the
draft,
and
one
of
the
interesting
things
we
saw
was
that
there
are
no
examples
so
far
that
have
multiple
component
optimization.
G
That
was
a
point
that
was
raised
during
the
the
hackathon
on
the
13th,
so
I
I
attempted
to
address
it
during
ietf
wii
hackathon
week,
but
I
only
got
part
way
through
I'm
afraid.
G
The
other
thing
that
was
raised
was
that
there's
a
an
interesting
problem
when
you
have
three
or
more
components
and
they're
not
all
handled
identically,
and
that
is
that,
if
any
one
component
needs
to
be
handled
differently
than
the
other
two,
the
encoding
that
we
have
for
specifying
that
multiple
components
are
targeted
by
a
set
of
commands
doesn't
work.
G
So
there
was
some
discussion
between
me
and
one
of
the
other
hackathon
participants
cohn
sorry,
and
we
came
up
with
another
suggestion
which
we'll
bring
up
during
the
the
manifest
discussion
later
on
kuhn
was
able
to
update
the
riot
parser
to
manifest
07
and
from
discussion
with
him.
I
gather
that
the
0
809
encoding
is
pretty
trivial
to
to
pick
up
from
there,
so
I
think
we're
all
in
pretty
good
shape
on
that
point
and
yichi
was
also
able
and
his
team.
I
suppose
I
I'm
sorry.
G
I
I
not
entirely
sure
how
many
people
were
on
your
team.
They
were
able
to
get
a
suit
and
tip
implementation
working,
which
is
also
pretty
exciting.
Now
I
we
didn't
actually
have
a
proper
scrub
at
the
end
of
either
of
these.
So
I'm
not
sure
quite
how
much
else
there
is
in
there
that
got
done.
Oh,
there
is
one
I
left
off.
We
were
able
to
get
an
hss
lms
implementation,
verifying
in
the
in
the
examples
in
the
suit
manifest
generator
repo.
So
that
was
pretty
good,
too
dave.
G
B
Just
that
in
my
progress,
that's
what
I
use
to
file
issues
mostly
against
the
teep
protocol,
implementation's
use
of
suit,
as
opposed
to
the
suit
manifest
it
did
affect
in
the
ietf
week.
I
did
my
suit
manifest
review
while
working
on
things,
but
during
the
13th
hackathon.
B
G
Great,
so
I
guess.
B
G
Okay,
so
next
slide,
please
right,
so
we
learned
that
multiple
component
handling
needs
a
little
bit
more
care
and
I
think
we've
got
a
solution
for
that
and
we
definitely
need
a
dependency
example,
so
that
that
was
feedback
from
multiple
hackathon
participants
that,
in
order
to
properly
handle
this,
there
does
need
to
be
an
example
for
that
all
right,
and
I
think
with
that,
that's
the
end
of
the
hackathon
report.
So
thanks
to
everyone
who
participated.
C
Thanks
brendan,
that
was
useful.
Are
there
any
questions
I
didn't
see
any
in
the
jabber
before
I
switched
over
to
this
window
to
manage
the
queue
all
right?
So,
let's
turn
to
the
architecture
document
that
has
been
submitted
to
the
isg
for
publication.
C
I
don't
believe:
we've
seen
any
review
as
a
result
of
that.
Yet
roman.
A
A
C
Right:
okay,
so
we
wait
and
see
when
we
get
the
any
last
call
comments.
Okay,
turning
to
the
information
model
also
submitted
to
the
isg.
A
Yeah
correct
that
one
is
still
with
me:
I'm
still
making
my
my
way
through
that
and
just
to
explain.
I
know
that
the
information
model
actually
was
technically
submitted
first
and
then
the
architecture
I
flipped
the
order,
because
I
wanted
to
read
the
architecture
before
I
read
the
information
model
and
in
the
process
I
was
done
with
the
architecture.
First.
C
That
that's
actually
a
much
more
reasonable
way
than
I
figured
that's
how
the
developer,
who
never
paid
it
was
part
of
this
would
look
at
it.
I
think
so
that
makes
sense
okay,
so
we
could
expect
to
see
that
reach
last
call
soon.
G
Sorry
about
that,
I,
I
guess
you
know,
lead
author.
What
can
I
say
you're
doing
great
all
right,
so
this
is
version
nine.
I
just
want
to
highlight
a
couple
of
things
up
front
version.
Nine
was
primarily
a
few
minor
changes
from
version.
Eight
version,
eight
is
what
I
presented
at
the
hackathon
on
the
13th.
G
The
changes
in
version
9
were
the
things
I
could
quickly
slip
in
from
feedback
on
the
from
the
hackathon,
so
they
are
explaining
their
explanatory
changes.
Primarily,
they
were
just
things
where
someone
in
the
hackathon
said
hey.
This
part
isn't
clear
to
me
and
I
said
oh
well,
I
mean,
if
I
finish
it
tonight,
then
maybe
it
can
be
clear
to
you
tomorrow.
So
that's
that's
about
it
for
changes
in
in
09,
nothing
more
than
just
those
kinds
of
things.
G
The
changes
in
oh
eight
were
more
slightly
more
substantial,
but
not
a
lot,
and
let's
get
into
that
next
next
slide,
please.
So
there
was.
There
were
organization
changes,
so
that
was
primarily
to
try
and
make
the
document
just
read
better
and
make
more
sense.
I
added
an
overview
of
the
metadata
structure.
This
largely
just
explains
how
the
metadata
fits
together
and
what
each
piece
is
for,
but
doesn't
go
into
encoding
at
all.
G
This
is
so
that
it
can
be
used
as
something
that
someone
can
be
expected
to
have
read
when
they
read
through
the
other
sections
that
come
before
the
meta
data
structure,
description,
because
the
the
metadata
and
the
and
the
processor
of
that
metadata
are
so
intertwined.
In
this
specification
it
makes
it
kind
of
difficult
to
say
here's
all
of
the
metadata,
but
I
can't
tell
you
why
it
is
the
way
it
is
yet.
G
B
Brennan,
if
I
understand
right-
because
I
did
do
the
review
of
this-
and
I
hadn't
thought
through
this
before
and
but
I
think
there
is
some.
If
I
understand
right,
there
is
some
amount
of
duplication
right
now,
where
you
go
through
a
high
level
stuff
and
then
the
the
same
set
of
stuff
lower
level
later
on
correct.
B
So
that
does
make
it
a
little
bit
longer
and
editorially.
There's
some
stuff
you're
going
to
clean
up
right,
where
they
use
different
terms
right
now,
the
high
level
term
and
then
the
actual
formal,
like
cddl
term
or
whatever,
and
sometimes
they're
kind
of
intermixed
and
stuff.
And
so
do
you
think
that
it's
actually
do
you
actually
want
to
keep
this
extra
layer
of
text,
or
is
this
extra
fluff
that
we
don't
need?
I
guess
is
what
my
meta
question
is,
and
I
don't
have
an
opinion
right
now
so
well
that.
G
Which
I'm
open
to
feedback
on
that
one?
If
I
just
want
the
document
to
read?
Well,
that's
that's
really
where
I'm
coming
from.
Yes,
if
there's
any
place,
you
know
anywhere
that
there
are
hangovers,
where
the
references
aren't
clear.
The
terms
aren't
clear.
Those
do
need
to
be
cleaned
up
and-
and
that's
of
course
something
that
I
expect
to
be
working
on
over
the
next
few
weeks.
But
the
I
mean.
B
G
Yeah
well
indeed,
I
guess,
then
the
question
is:
should
should
we
merge
that
back
together
again
and
and
that
brings
back
another
organization
question
which
is:
should
the
should
the
metadata
be
fully
described
before,
there's
any
discussion
of
how
it's
processed
or
should
the
processing
be
fully
described
before
you
have
any
definition
of
exactly
what's
being
processed.
G
We'll
make
a
choice
and
and
cut
it
down
to
only
one
that
seems
like
the
feedback
from
russ
there.
B
E
Say:
okay,
I
thought
that
you
guys
moving
from
a
queue
to
the
speaker
slot,
but
so
there
were
a
few
organizational
document
changes
before
the
current
version
and
it
turns
out
to
be
somewhat
difficult
to
describe
it
in
a
the
whole
concept
in
a
an
easily
understandable
way,
and
so
I
think
it's
best
if
you
just
read
through
it
and
and
see
whether
that
sort
of
like
whether
you
get
the
idea
and
and
if
not
then
obviously
we
need
to
change
it,
but
even
the
previous
versions.
E
G
Okay-
well,
I
don't
know,
maybe
if
I
could
get
some
reviews
from
people
just
on
the
readability
on
the
list.
That
would
be
really
helpful.
G
I
added
a
template
for
a
b
firmware
image
selection
and
that
has
removed
the
need
for
the
previous
section
on
using
conditional
sequences.
I
think
that
this
reads
much
better
and
is
a
much
more
usable
result.
G
I've
added
the
names
of
templates
to
each
example.
So
now
that
the
examples
actually
say,
this
is
an
instantiation
of
templates,
a
b
and
c,
and
that
hopefully,
will
also
improve
the
usability
of
the
document
a
lot
of
the.
So
there
are
a
lot
of
minor
changes,
and
I
I
don't
think
those
are
particularly
controversial
or
need
much
highlighting,
but
they
are
listed
there
in
case.
You
want
to
have
a
look
at
them,
but
I
don't
think
we
should
take
the
time
on
going
through
them.
G
You
know
with
a
fine-tooth
comb,
so
next
slide,
please
so
two
big
changes
to
encoding.
I've
removed
byte
string
wrappers
from
the
dependencies
list
and
from
the
components
list,
so
this
was
essentially
feedback
from
implementers.
G
Originally,
I'd
put
these
in
because
I
thought
they
would
make
it
easier
for
the
parser
to
handle
and
it
turns
out
that
it
didn't
make
much
difference.
So,
with
that
being
the
case,
it
doesn't
make
sense
to
have
them.
So
I
took
them
out
and
suit
common
dependency.
Components
was
supposed
to
be
a
mechanism
for
a
very
constrained
parser
to
be
able
to
identify
exactly
which
components
it
was
going
to
modify
and
whether
it
would
be
able
to
handle
all
of
that
right
at
the
very
beginning.
G
On
the
first
manifest,
however,
it
does
introduce
an
implementation
pitfall
and
that's
where
one
one
at
the
one
manifest
lies
about
exactly
which
components
it
affects,
and
then
the
parser
believes
it,
and
that
causes
a
problem
later
down
the
parsing
chain
and
because
that
means
that,
with
a
dependency
setup,
it
might
not
be
authoritative.
G
I
don't
know
if
that
makes
sense
all
right
next
slide,
please
so
I
refracted
the
text
block,
and
this
is
largely
because
the
text
block
was
component
specific
or
wasn't
component
specific
previously,
and
it
does
need
to
be
able
to
describe
individual
components
for
it
to
be
useful.
So
essentially,
what's
been
done
here
is
we've
added
a
a
set
of
component
specific
text
elements
and
each
one
of
those
is
identified
inside
a
component
level
map,
so
that
should
make
it
a
lot
more
usable
for
describing
more
complex
updates.
G
G
That's
basing
its
reports
on
the
super
processor's
output,
and
we
also
added-
and
you
know,
as
a
natural
follow-on
from
that
we
thought
about
what
a
report
object
from
one
of
these
reports
might
look
like
and
then
sort
of
wrote
that
down
and
put
it
in
the
in
a
long
as
an
optional
element.
G
Now
there's
been
some
discussion
on
the
list
about
whether
this
is
in
fact
the
right
place
for
that
object,
and
so
I
guess
my
one
of
the
questions
I
have
for
the
list
today,
which
we'll
get
on
to
in
a
minute,
is
whether
that
needs
to
be
moved
out
to
a
different
document.
G
Next
slide.
Please.
B
So,
just
one
comment
on
the
second
bullet:
the
reporting
policy
and
feel
free
to
defer
it.
If
you
actually
have
this
on
a
slide
later,
the
hints
for
attestation
and
hints
for
reporting
are
not
necessarily
synonymous
if
you
have
a
reporting
mechanism,
in
addition
to
what's
an
attestation.
G
So
what
this
does
is
it
makes
no
assertions
about
what
which
one
of
those
it
is.
The
the
point
is
that
you
have
some
kind
of
reporting
engine
and
if
your
reporting
engine
happens
to
be
an
attestation
system,
then
what
you
get
is
an
attestation
report.
If
it
happens
to
be
a
logging
system,
then
what
you
get
is
a
log.
It's
not
it's
not
being
prescriptive
in
that
way.
The
the
the
important
thing
to
consider,
though,
is
that
if
what
you're
doing
is
writing
a
bootloader,
then
the
report
and
and
your
bootloader
isn't
networked.
G
I
guess
that's
the
other
part,
then
the
report
has
to
be
armored
against
tampering
by
the
primary
application,
and
so
that
becomes
an
attestation
report
that
I
mean
or
a
signed
log,
which
effectively
is
an
attestation
report
at
that
point.
So
that's
why
attestation
is
called
out
specifically
and
saying
that
that
is
one
of
the
vehicles
you
might
want
to
consider,
and
it's
essentially
because
this
we
have
taken
the
bootloader
use
case
into
account
and
because
we've
got
the
bootloader
use
case
there.
We
also
have
to
talk
about
what
reporting
means
for
a
bootloader.
B
H
Actually,
brendan
on
the.
H
One
you
would
ask
if
there
was
any
any
concerns
about
the
third
bullet.
Yes,
maybe
do
you
have
a
separate
slide.
G
No,
that's
all
right,
don't
worry,
so
I've
got
some
examples
that
have
been
changed
so
that
the
goal
here
was
to
take
a
much
more
structured
approach
to
the
examples
that
are
there
and
to
say.
Essentially,
each
template
should
have
one
example
and
if
an
example
isn't
adding
to
the
number
of
templates
that
are
covered,
then
it's
not
necessary.
G
But
there
are
a
few
elements
that
are
missing
so
there
there
is
the
question:
do
we
need
more
examples?
The
dependency
example
has
been
largely
requested.
I
haven't
seen
anyone
say
no,
please
don't
put
a
dependency
example
in,
but
there
is
still
an
open
question
as
to
integrated
payloads
encrypted
payloads
and
encrypted
dependencies.
G
Now,
the
sorry,
someone
will
have
to
remind
me
of
the
name
I'm
going
to
get
this
wrong.
The
human
rights
review
that
we
had
done
specifically
with
regards
to
privacy
asked
for
encrypted
metadata,
so
I'm
wondering
whether
providing
an
encrypted
dependency
example
would
be
the
best
way
of
fulfilling
that
ask.
B
That
sounds
reasonable
to
me.
I
will
just
report
out
from
the
teep
meeting.
We
also
discussed
in
teap,
which
has
come
up
in
suit
before,
but
we
discussed
in
teep
about
where,
to
put
an
example
of
use
of
suit
for
teep
and
brendan
and
the
rest
of
the
working
group.
I
think
we
agreed
that
that
was
going
to
be
in
teeth,
and
so
the
answer
here
do
we
need
more
examples
in
the
soup
manifest.
The
answer
would
be
no
for
teeth,
because
we
would
put
that
into
the
t.
B
Protocol
was
the
agreement
there,
as
I
understood
so,
okay,
and
so
one
of
the
type
use
cases
that
was
relevant
to
that
discussion
was
when
the
client
already
has
the
relevant
binary
and
what's
coming
in
the
suit
manifest.
Is
the
steps
necessary
to
install
the
binary?
That's
already
present
locally,
and
so
this
is
a
case
where
say
the
trusted
binary
gets
distributed
along
with
the
untrusted
binary.
The
untrusted
binary
includes
a
suit
manifest,
that's
how
you
get
the
instructions
or
permission
to
install
that
trusted
binary
into
the
tee.
B
B
Yeah,
so
I'm
just
reporting
out
that
the
teep
said
this
is
a.
This
is
a
set
of
suit
examples
that
needs
to
be
discussed,
but
it's
going
to
continue
discussion
and
t,
but
we're
going
to
want
suit
review,
and
so
that's
why
it
will
continue
to
be
maybe
cross-posted
between
the
two
lists,
but
formally
in
the
document.
It
shouldn't
affect
this
document.
So,
okay.
G
So
now
we
get
on
to
the
questions,
and
this
is
the
audience
participation
instead,
which
next
slide
please
all
right,
so
packed.
Seabor
is
probably
the
most
contentious
thing
for
today
packed
seabor.
It
would
provide
a
really
substantial
size.
Savings
in
suit
and
and
suit
actually
has
has
built
in
some
of
the
features
that
packed
seaboard
presents
just
not
in
quite
the
same
way,
and
certainly
not
in
anywhere
near
as
generic
a
way
suit.
G
Common,
for
example,
does
exactly
what
packed
seabor
does
in
taking
commonly
used
elements
and
then
making
them
referenceable
easily,
so
there
overall,
I
think
if,
if
packed
seabor
had
been
standardized
yesterday,
I
would
say:
let's
do
this,
but
the
problem
is
that
packed.
Sibor
has
only
just
been
adopted
by
the
seabor
working
group
and
it's
missing
a
few
features
that
we
probably
want,
namely
in
the
in
this
the
the
zero
zero
specification
itself.
G
It
calls
out
the
the
possibility
for
adding
nested
packed
seabor
objects,
which
we
would
absolutely
want,
and
also
it
calls
out
the
the
need
for
packing
seabor
sequences
or
the
possible
need,
and
we
would
again
definitely
want
that.
That's
precisely
what
the
common
sequence
encodes
today
there's
also
a
question
as
to
whether
the
the
packed
seaborn
encoding
is
pull
parser
friendly.
Now,
I
think,
there's
a
fairly
straightforward
work
around
to
make
it
pull
parser
friendly,
but
there
there
would
have
to
be
the
question
about
that.
G
So
we've
got
a
few
choices
here.
We
could
make
no
change
and
just
apply
packed
seabor
over
top
of
suit
and
just
not
really
say
anything
about
it
at
all.
We
could
also
really
simplify
suit
and
use
packed
seaborg
to
gain
back
the
the
deduplication
that
the
common
block
gives
us
today.
G
There's
also
the
the
possibility
of
adopting
packed
seaboard
right
now,
but
then
suit's
not
going
to
be
done
until
packed,
sebor
is
done
and
the
the
only
estimate
I
have
seen
so
far
on
that
is
we'll
be
lucky
if
it's
under
a
year,
so
given
the
maturity
of
suit
today,
I
do
wonder
if
that
is
the
right
approach.
I
suspect
it's
not.
G
Yep,
so
I
guess
this
is
where
we
need
the
working
group
feedback.
I
think
my
my
preference
is
likely
going
to
be
towards
keeping
what
we've
got
but
building
a
version
two
with
packed
seabor
as
and
when
that
becomes
appropriate,
and
if
we
can
justify
it
based
on
the
gains
that
it
provides.
G
The
the
concern
I
have
with
that
approach
is
that
it
will
fracture
any
ecosystem
that
we're
creating,
because
there
will
now
be
these
two
different
formats
out
there,
and
I
I'm
naturally
worried
that
the
second
one
will
get
nowhere
near
the
uptake
as
the
first,
because
the
first
one
came
first,
so
I'm
not
entirely.
C
G
That
also
so,
I
guess
the
question
is
to
the
working
group.
What
should
we
do.
I
Hi
this
is
hank
yeah,
while
pact
is
very
promising.
I
have
to
agree
with
option
two,
it's
basically
by
eliminating
the
other
options.
So
all
this
is
not
great,
it
should
have
been
yeah
a
time
machine
and
then
this
would
be
great,
but
I
think
waiting
for
it
is
simply
not
feasible
enough
and
I
really
hope
for
a
transition
to
version
two.
In
that
case,.
B
So
brendan,
I
think,
technically
speaking,
I
think
this
problem
is
not
suits
is
probably
not
the
only
group
that
is
facing
this
issue
correct
and
so
technically
there
is
another
option
which
you
kind
of
said,
implied
verbally
and
maybe
it's
part
of
the
first
bullet,
which
is
if,
for
example,
there
was
not
significant
say
savings
in
terms
of
number
of
bytes.
The
answer
would
be
make
no
change
and
never
apply
pack
seaport
right.
That
would
be.
G
B
Oh
okay,
right,
that's
kind
of
what
we're
doing
right
now,
right.
J
Go
ahead
so
so
18
months
was
said,
for
I
think
pax
seabor
to
get
to
rfc
because
it
doesn't
have
any
dependencies
and
it's
not
going
to
get
on
any
it's
not
going
to
get
in
any
one
of
those
group
things.
J
So
I
I
think
we
should
be
clear
that
I
don't
think
that
that's
necessarily
the
time
to
a
stable,
packed
sibor
that
could
be
much
shorter,
but
that
we
would
sit
in
the
rfc
cui
as
a
misref
for
18
months,
which
is
probably
undesirable
for
the
reasons
that
russ
said
is
that
people
may
not
be
willing
to
implement
until
rfc.
J
So
I
I
concur
with
brendan
and
I'm
really
sad
that
we
didn't
realize
this,
and
I
think
that
that
the
seabor
people
also
are
really
like.
Oh,
but
this
was
just
waiting
in
the
cute
wings
because
we
had
other
work
so
more
crossword
develop
more
crosswork
review
and
thoughts.
I
guess
is
needed
here.
G
I
mean
on
the
bright
side.
What
this
does
mean
is
that
we,
as
suit
can
have
some
influence
on
how
packed
seabor
is,
is
built
so
that
it
does
deal
with
our
particular
use
case
nicely.
So
I
mean
that
that's
the
one
bright
side
that
I
can
see
coming
out
of
this.
G
Well
from
the
comments
on
the
on
the
mic
so
far,
I
I
think
that
pretty
much
everyone
is
saying:
let's
not
do
anything,
let's
proceed
as
we
are,
and
if
we
can
prove
that
there's
a
substantial
benefit,
then
we
should
do
something.
G
Later,
but
I
I
think
that
even
the
part
where
I
I
wrote,
begin
work
on
v2,
maybe
that's
actually
wrong
and
the
the
real
answer
is
that
we're
not
actually
going
to
even
talk
about
suit
v2.
Until
we
can
prove
that
there's
a
substantial
benefit
which
hopefully
will
deal
with
dave's
concern
about
stalling
adoption,
or
was
that
russ
stalling
adoption
of
v1
due
to
the
oncoming
of
v2.
B
Stick
myself
in
queue.
I
just
wanted
to
get
at
the
end
of
the
queue,
since
I
can't
see
the
queue.
I
guess
at
this
point.
If
I'm
going
to
act
as
a
participant,
then
ross,
I'm
just
say
out
loud,
add
me
to
cue
and
then
you
can
manage
when
I
come
in
so
but
since
the
queue
seems
to
be
empty
right
now
I
mean
the
same
thing
would
happen
any
time
that
we
were
to
do
any
addition
in
suits.
So
let's
say
in
the
future.
B
You
know
we
decided
we
needed
a
new
directive
or
we
needed
a
new
condition
or
whatever
we'd
be
introducing
the
same
problem
ourselves
right.
So
this
is
just
another
instance
of
that.
As
long
as
we
can
keep
backwards
compatibility,
I
think
which
would
be
the
the
key
thing
you
still
have
the
issue
of
when
generating
a
manifest.
I
still
have
to
know
which
variation
or
which
options
or
which
you
know
mandatory.
B
You
know
directive
or
condition
or
whatever,
that
the
parser
is
going
to
support
and
on
the
parser
side
I
still
have
to
know
if
there's
multiple
ways
to
encode
stuff
in
the
suit
manifest,
which
one
am
I
implementing
the
latest
one
or
an
older
one
in
case
there's
an
older,
manifest
generator
and
so
on.
So
I
think
it's
just
a
problem.
We're
going
to
end
up
with
no
matter
what,
even
if
even
if
pax
seaborn
didn't
introduce
it
sooner
or
later,
we
think
we'd
run
into
the
same
issues.
So.
G
That's
that's
where
the
the
capability
reporting
right
discussion
comes
in
and
the
capability
reporting
side
of
things
is
is
a
bit
simpler
because
it
just
deals
with
you
know,
send
me
a
list
of
exactly
which
commands
you
support
and
then
I
can
compose
a
manifest
for
you,
but
this
is
a
little
bit
more
fundamental
than
that,
because
it's
about
how
the
the
manifest
itself
is
encoded
and-
and
this
is
where
the
difference
comes
in
when
you're
talking
about
capability
reporting-
it's
reasonably
straightforward,
because
it's
just
going
to
be
this
list
of
command
identifiers,
but
when
it
comes
to
the
encoding
of
the
manifest
itself,
that
requires
a
different
reporting
element.
G
B
G
Right,
yeah
and
then
algorithms
and
parameters.
B
G
Yeah-
and
I
think
I
think
the
thing
I
think
you've
got
the
right
answer
there
and
what
we
probably
need
to
do
is
have
a
capability
reporting
draft
and
I
don't
think
that
that
belongs
in
the
manifest
draft.
I
think
it's
a
separate
draft
yeah
it
for
one,
because
I
don't
want
this
to
get
any
bigger,
but
I
think
the
that's
probably
the
right
answer.
B
I
I
think,
you're
right,
because
the
capability
reporting
isn't
part
of
the
suit
manifest
itself
right.
So
I
I
agree
with
your
conclusion
for
the
same
reason
as
I
have
the
opinion
about
a
different
topic
which
we'll
eventually
get
to
yeah
all
right.
B
K
Yeah,
so
just
a
quick,
I
guess
comment
about
the
packed
seabor
slash
question:
will
the
packed
representation
be
optional
when
it
is
added,
and
if
so,
would
that
basically
be
an
extension
of
what
we
have
now
or
is
this
a
completely
different
variant?
K
G
So
so
there
are
two
options:
the
first
is
to
just
pack
what
we've
got
and,
and
that's
fine
and
that'll
probably
be
pretty
good,
but
there's
another
option
which
is
potentially
better
it's
hard
to
say
and
and
that's
one
of
the
reasons
that
until
packed
seabor
itself
is
fun
stable
and
until
we
have
proven
which
of
these,
we
should
do
where
it
might
be
better
just
to
hold
off.
The
second
option
is
essentially
that
we,
we
redesign
how
we
are
implementing
the
manifest
with
packed
sibor
in
mind
from
the
beginning.
G
Essentially,
this
means
things
like
right
now
we
have
a
component
index.
Well,
that's
not
necessary
if
you're
packing
everything
instead
of
having
a
component
index.
What
you
do
is
you
just
put
the
full
component
id
everywhere,
you're
using
it,
knowing
that
the
the
packing
system
will
deduplicate
that,
for
you,
it
comes
out
to
the
same
effect.
G
But
what
that
means
is
that
the
structure
of
the
of
the
manifest
seaboard
becomes
much
simpler
if
it's
fully
unpacked
and-
and
so
this
is
essentially,
why
I'm
talking
about
whether
it
would
be
v2
or
just
run
the
packing
right
over
top
of
it,
and
that's
something
that
I
think
we're
going
to
have
to
discuss
on
the
list.
If
and
when
it
comes
to
that
point,
and
I
wouldn't
see
making
that
change
unless
there
was
an
obvious
and
substantial
benefit
over
top
of
just
running
the
packer.
Over
top
of
the
manifest.
E
Hi
yeah,
I
was
just
on
the
capability
reporting.
I
just
wanted
to
mention
that
we
have
some
at
least
basic
form
of
capability
reporting
in
the
deep
protocols,
because
after
all,
this
is
more,
in
my
opinion,
more
a
protocol
aspect.
E
Of
course,
the
what
capability
we
are
reporting
depends
on
what
what
is
supported
in
in
terms
of
commands
and
conditions
in
the
manifest
but
and
so
on,
and
but
that
needs
to
be
communicated
from
the
device
to
let's
say
a
cloud
or
whatever,
but
maybe
it
needs
some
more
or
the
details
need
to
be
more
explicitly
specified.
G
G
Okay,
I
guess
then,
let's
go
on
to
the
next
slide.
G
I
think
this
one's
much
more
straightforward
right
now,
we've
got
several
different
cozy
objects
that
we
can
support.
G
What
this
does
for
us
is.
It
enables
modular
processing
of
large
signatures.
That's
sorry,
apologies
we
can
each
cozy
signature
and
mac
object
has
a
suit
digest
in
it.
The
point
of
this
was
twofold:
first,
it
was
to
enable
modular
processing
of
large
signatures.
Second,
it
was
it
was
put
in
because
eddsa
was
in
cozy
does
not
have
the
eddsa
with
hash
variant.
Now
I
think
that's
a
minor
thing.
It
probably
doesn't
apply
to
the
devices
we're
using,
but
at
the
same
time,
the
modular
processing
of
large
signatures,
particularly
pqc
signatures.
G
I
think
that's
what
the
more
important
question
is
and
and
modular
processing
just
to
be
clear.
What
I
mean
by
that
is
that
you
don't
have
to
hold
the
entire
manifest
in
memory
while
calculating
the
signature.
G
C
G
Let
me
let
me
explain
the
the
the
core
of
the
problem
here.
What
what
you
have
when
you
have
something
like
a
2k
signature
on
an
object
is
a
situation
where
you
have
to
start
by
calculating
the
digest
that
you're
going
to
verify
that
signature
against,
and
so
that
means
constructing
the
the
cozy
signature
object
in
this
case
and
part
of
the
cozy
signature
object
is
the
the
payload
itself.
G
So
if
you're
going
to
do
this,
you
have
to
then
move
forward
in
space
to
where
the
the
signed
object
actually
is,
and
that
signed
object
is
the
manifest
and
it
comes
after
the
signature
in
the
network
byte
ordering
right.
So
as
as
you
receive
this
thing,
you
you,
you
can't
actually
process
the
signature
until
after
the
full
signature
has
been
received
and
then,
after
the
manifest
block
itself
at
minimum,
has
been
received,
then
you
have
to
seek
back
to
where
the
signature
is
and
process
the
signature.
G
So
this
is
an
exercise
in
bringing
that
out
into
a
linear
order
by
putting
the
suit
digest
in
the
cozy
signature
object
that
allows
us
to
to
just
authenticate
a
small
block.
The
signature
itself
save
that
and
then
verify
the
manifest
against
that
authenticated
digest.
Once
the
signature
has
been
processed.
G
G
Oh
okay,
so
essentially
the
idea
here
is
that
we
put
a
suit
digest,
which
is
a
seabor
array
of
an
algorithm
identifier
and
the
raw
digest
bytes
in
the
cozy
signature
payload,
and
we
do
that
in
line
not
detached.
G
This
is
how
we're
doing
it
today
and
the
the
digest
itself
applies
to
the
manifest
and
because
of
doing
it,
this
way
you're
able
to
calculate
in
a
linear
fashion,
the
the
cozy
signature
object,
which
allows
you
to
verify
it
against
the
signature
before
even
necessarily
receiving
the
rest
of
the
manifest
object
and
the
this
has
a
few
advantages,
but
it
essentially
comes
down
to
being
able
to
process
in
a
modular
way.
G
You
don't
have
to
load
everything
into
ram,
you
don't
have
to
seek
forward
and
backwards,
and
when
we're
talking
about
things
that
are
stored,
for
example,
in
external
flash,
this
has
power
and
processing
time
cons
consequences.
When
we're
talking
about
things
that
are
received
on
the
wire
and
immediately
rejected.
This
has
bandwidth
considerations.
It's
got
energy
considerations,
it
it
has
ripple
effects,
but
it
costs
one
suit,
digest
per
object.
B
G
So
it's
a
change
and
it
takes
a
couple
more
bites.
I
think,
or
is
it
three
more
bytes
roughly
in
singly,
authenticated.
B
So
that's
that's
the
question.
I
don't
know
what
happened
to
russ,
but
he
was
some
saying
something
about.
So
that's
an
extra
layer
of
indirection
and
I
think
he's
just
confirming
he
understood
what
you
said
that
you're
trying.
G
Okay
yeah,
so
this
is
essentially
about
adding
a
layer
of
in
no
the
the
original
adds
a
layer
of
indirection.
What
I'm
suggesting
is
that,
if
you
were
to
authenticate
multiple
things
in
this
way,
what
you
would
end
up
with
is
multiple
repeated
digests.
Now,
if
we
were
to
use
packed
sebor,
this
would
be
irrelevant,
but
in
the
absence
of
packed
sibor,
we
have
to
ask
the
question:
should
we
take
the
suit
digest
out
and
put
it
into
its
own
element?
Probably
the
first
element
in
the
authentication
object
array.
G
G
Okay,
I
think
we've
probably
spent
more
time
than
we
needed
to
on
that.
Let's
go
on
to
the
next
one,
so
vendor
id
was
a
a
hot
topic
this
week.
The
the
current
construction
of
vendor
id
is
that
it
is
a
a
uuid
and
the
composition
rules
for
it.
Don't
actually
matter
at
this
point.
It's
just
that
it's
a
uuid
the
advantage
to
using
a
uuid
like
this
is
that
it's
well.
G
If
you
have
a
domain
name,
it's
free,
it's
fixed
size,
it's
unique
because
of
domain
name,
uniqueness
and
and
it's
easily
computable.
If
you
know
something
about
who
the
vendor
might
be,
I
does
have
disadvantages.
Reverse
lookup
is
a
huge
pain
and
if
you
change
your
domain
name,
suddenly
you
can't
compute
it
anymore
and
it's
16
bytes.
G
So
a
a
couple
of
counter
proposals
were
raised.
The
first
was
oui
I.
I
am
not
a
fan
of
using
oui
for
this
particular
use
case,
because
oui
has
a
certain
number
of
implications.
Organizations
who
are
manufacturing.
These
things
may
not
already
have
ouis
and
asking
people
to
pay
three
thousand
dollars
just
to
sit
at
the
table
doesn't
seem
like
the
right
answer.
G
Private
enterprise
number
is
certainly
more
interesting
to
me.
I
don't
think
that
it
has
like.
I
don't
think,
there's
a
big
disadvantage
here.
I
think
it's
probably
the
right
answer.
I
think
that
it
just
introduces
a
little
bit
of
explanatory
text
about
exactly
how
we
use
it.
So
the
first
thing
that
we
we
discussed
was
what
about
sub
registrations,
so
it
turns
out
it's
not
going
to
be
just
a
number.
G
I
mean,
I
sure,
hope
they
do
and
the
the
result
of
this
is
going
to
be
that
you
have
to
be
able
to
distinguish
between
them,
and
maybe
it's
possible
to
do
that,
just
based
on
class
ids.
But
it
seems
like
it's
it's
better
to
consider
the
larger
case
at
this
point
in
time.
G
So
I
think
we
do
need
to
consider
sub-registrations,
it's
still
not
necessarily
robust
against
spin-outs.
So
if
you
have
these
two
sub-organizations
within
your
organization-
and
you
decide
that
one
of
them
is
no
longer
part
of
your
organization,
it's
a
new
organization
that
is
going
to
change
a
the
vendor
id
effectively.
They'll
have
to
register
for
a
new
one,
and
that
is
not
a
blocker
either.
That
probably
means
that
they
have
to
update
their
devices
firmware.
G
So
I
I
just
think
that
we
we
need
to
essentially
document
that
these
are
the
processes.
If
we're
going
to
use
a
private
enterprise
number
rather
than
using
a
uuid
and
the.
F
G
Queue,
okay,
rough
booking
and
cube,
and
the
final
thing
that
it
comes
out
to
here
is
that
or
sorry.
The
final
bit
of
complexity
is
that
rfc
4122
didn't
actually
explain
how
you
build
a
an
oid
based
namespace
identifier,
and
we
use
the
vendor
namespace
identifier,
to
construct
the
class
id.
So
we
still
need
to
build
a
uuid
out
of
this,
even
if
it's
just
to
construct
the
class
id,
and
so
what
that
means
is
that
we'll
have
to
define
that
or
we'll
have
to
define
a
private
enterprise
number
variant.
G
C
Okay,
so
the
queue
is
me
and
then
dave.
I
want
to
observe
that
if
the
enterprise
were
to
use
a
subdomain
for
various
things,
not
domain
but
a
ver
arc
within
the
private
enterprise,
when
it
sold
off
a
chunk
of
the
company
as
your
example,
the
spinout,
they
could
delegate
that
arc
with
the
sellout.
And
so
then
there
wouldn't
be
any
change.
B
Yeah,
so
just
on
the
three
disadvantage
points,
I
think
it
is
simplest
to
just
define
a
new
uuid
and
not
try
to
co-op
some
other
one,
but
that
will
get
to
my
points
on
the
other
things.
Your
third
disadvantage
is
the
common
disadvantage
between
both
of
those
and
so
that
one
is
not
really
a
tiebreaker
disadvantage
of
either
of
them.
It's.
B
I
just
have
a
couple
comments
here
at
the
on
the
sub
registration.
One
is
the
main
main
thing
I
want
to
get
to
okay,
because
if
you
think
about
sub
registration
with
the
dns
name,
space
right
anytime,
that
you
have
a
sub
one
you're
going
to
end
up
with
a
completely
different
uid,
that's
not
related
to
the
previous
one
right.
It's
not
like!
B
You
can
tell
from
two
uids
that
one
is
a
subdomain
of
the
other
right
without
without
actually
knowing
the
domain
that
the
uids
was
generated
from
which
you
may
not
know
right,
and
so
the
point
is
in
the
private
enterprise
number.
If
you
have
a
sub
one
they're
free
right,
you
could
just
generate
a
brand
new
private
enterprise.
Number
there's
no
need
to
nest
them,
because
you
couldn't
observe
that
between
two
uuid's
in
the
first
place
right
right,
the
ayanna.
H
G
B
Yeah,
thank
you.
I
think
I
may
have
another
point,
but
I've
now
forgotten.
Oh,
I
know
what
it
was
not
on
this
slide,
but
all
of
this
discussion
here,
I'm
wondering
now
whether
any
of
this
discussion
applies
because
the
remember
all
of
this
was
because
I
observed
that
there
were
two
disadvantages
that
I
didn't
like
on
the
uid
scheme.
One
was
the
reverse
look
up
and
the
other
one
was
the
16
bytes
versus
you
know
one
or
two
bytes,
or
something
like
that
right.
B
I'm
wondering
whether
any
of
this
would
apply
to
class
id
as
well.
I
don't
know
generator
okay,
because
you
could
say
within
my
own
vendor
id
I'm
going
to
self-manage
my
own.
You
know
uint
space
and
use
the
same
construction
such
that
I
don't
put
the
full
16
bytes
in
there.
I
put
you
know
one
or
two
bytes,
whatever
the
whatever
the
id
is:
that's
used
to
generate
the
uid
from.
G
So
I
don't
have
a
technical
argument
against
that.
Instead,
I
have
a
human
nature
argument,
and-
and
the
point
here
is
that
it's
not
human,
readable
text
and
more
than
that
for
class
ids,
it's
not
reverse
lookupable
and
that's
actually
an
important
property.
I
don't
want
people
to
try
and
make
it
something
that
they
can
reverse
look
up.
G
That's
what
the
text
sections
for
the
whole
exercise
here
is
to
make
it
very
very
clear
to
developers
that
they
should
put
every
single
piece
of
model
information
in
there
that
everything
that
could
possibly
affect
compatibility
should
absolutely
be
a
part
of
their
class
identifier
and
as
soon
as
you
have
something
that
a
customer
can
look
up,
your
marketing
department
gets
involved
and
as
soon
as
your
marketing
department
gets
involved,
suddenly
you
have
a
situation
where
these
two
models
with
incompatible
devices
on
them
have
to
be
identified
as
the
same
model
in
any
customer
facing
portal
and
suddenly
the
whole
exercise
that
we
had
here
to
construct
a
situation
where
you
can't
have
robustness
failures
due
to
mixing
up
two
models.
B
I
buy
your
argument
around
the
lookup
point,
although
one
could
argue
that
a
class
id
that's
a
uid
is
still
just
as
lookupable
as
a
as
a
number
is
to
an
outside
observer
right.
Only.
B
Right,
it's
only
if
it
was
a
published
database
right.
If
there's
no
published
database,
then
it's
equally
not
lookupable
right.
It's
only
internally
lookupable
by
that
particular
vendor,
and
as
you
can
do
comparison
that
says,
oh,
I
happen
to
know
that
this
particular
one,
because
I've
seen
it
before
is
this
one,
because
I
bought
one
of
those
and
therefore
every
other
one
must
be,
and
then
it's
exactly
the
same.
So
I
think
the
pain.
B
B
B
These
are
good
discussions
because,
again
you're
the
whole
point
of
yours,
pepsi
bar,
was
to
say
how
much
compression
could
we
get,
and
maybe
pack
seaport
gives
us
much
more
and
this
could
affect
the
size.
You
know
I
don't
know
if
it
significantly
depends
on
how
big
your
full
manifest
is,
but
we're
talking
about
tens
of
bytes
so.
G
Well,
the
entertaining
thing,
of
course,
is
that
if
we
introduced
packed
seabor,
we
could
cut
this
discussion
right
now,
because
all
you
have
to
do
is
have
a
default
dictionary
that
lives
on
your
device.
That
happens
to
contain
the
correct
namespace.
B
B
You've
heard
my
observations
and
things
and
then-
and
what
do
you
think
do
you
have
an
opinion
as
to
other
different
things
you
just
talked
about?
Sometimes
we've
collectively
talked
about.
Are
there
any
of
those
that
you
like
best
at
this
point
I
I'm
undecided,
but
on
the
on
the
vendor
id
I
like
the
pi
pen
stuff,
and
I
think
you
are
right,
but
for
the
more
general
discussion
is
there
anything
we
think
we
should
do.
G
I'm
not
opposed
to
using
pn
for
the
namespace
for
the
the
vendor
id
it.
It
makes
sense
to
me.
The
important
thing
is
that
it's
unique
that's
what
we
really
care
about,
because
registration
is
free.
I
don't
think
there's
a
big
deal
there.
I
would
ask
how
it's
going
to
affect
organizations
that
don't
want
to
expose
their
existence
publicly
on
a
registry
like
that,
so
there
is
a
question
there
as
to
whether
we
care
about
those
organizations
and
we
we
essentially
have
to
decide
that.
G
G
I
I
take
your
point
that
your
company
doesn't
have
to
publish
their
their
oid
to
device
mapping,
but
my
experience
has
been
that
if
it's
possible
someone
will
say
we
should
do
that
and
then
marketing
gets
involved.
So
I
I
appreciate
the
compression
argument.
I
I
do
see
where
you're
coming
from
that,
but
I'm
not
convinced
that
it's
going
to
solve
the
problem.
G
That
might
be
the
optimal
answer.
I'm
not
sure.
I
Hi
yeah
this
is
hank.
There
are
multiple
ways
to
address
this.
I
don't
want
to
disclose.
That's
me
in
the
vendor
space.
First
of
all,
you
can
always
cut
a
number
space
like
pens
in
half
by
using
negative
numbers,
and
then
you
can
do
a
type
choice
here
and
put
anything
in
there.
I
That
is
suddenly
not
a
number
or
a
positive
integer,
sorry
and-
and
that
makes
it
very
obvious
that
you
don't
want
to
disclose
something,
because
now
it's
a
string
also
it's
bigger
and
or
it's
bytes,
whatever
it's
a
bite
of
string
and
and
the
whole
thing
is.
If
you
allow
for
non-disclosure
or
anonymity
here,
then
you
lose,
and
it
is
my
assumption.
Maybe
you
know
better
bren.
You
lose
collision
known
collisionless
here
you
might
have
accidental
collisions,
then
right
if
it's
not
in
a
registry,
how.
G
Well,
that
was
the
point
of
unique
identifiers
that
that's
where
your
collision
resistance
comes
from.
I
G
You
have
two
choices
in
in
in
producing
uniqueness,
the
first
is
probability
and
then
you
get
that
through
cryptography
or
randomness,
and
the
second
is
authoritarianism
which
are
you
going
to
pick.
We
have
the
choice,
yeah
and
then
yeah.
I
I
Ayanna,
of
course,
is
not
so
so
what
what
you
can
do
here,
I
think,
is
to
have
a
choice,
as
you
just
say,
of
using
a
positive
integer
or
a
byte
string.
G
Yeah-
and
maybe
that's
you
know,
the
interesting
thing
here
is:
if
we
did
allow
for
a
byte
string,
then
the
recommended
method
for
constructing
the
byte
string
could
of
course
be
using
your
vendor
domain
and
then
that
just
drops
us
down
to.
We
add
the
option
of
using
a
private
enterprise
number
and
hey
look.
We're
done.
B
Yeah,
I
don't
know
if
there's
other
people
in
queue,
but
I
I
love
hank's
idea.
We
kind
of
already
have
in
the
I
think
it's
the
component
index,
where
it
could
be
two
different
types,
whether
it's
an
inch
or
a
bull
right,
because
you
can
set
the
component
index
to
true,
and
so
this
already
notion
that
says
you
use
two
different
types
to
distinguish
and
I
love
hank's
ids.
So
I
think
that's
that
would
be
fine.
B
It
says
you
could
use
a
uuid
or
whatever,
if
you,
if
you're
in
that
category,
but
that's
not
the
recommended
one.
K
G
So
the
original
goal
of
the
uniqueness
here
was
to
deal
with
two
common
problems.
The
the
first
problem
is
my.
My
one:
vendor
produces
two
devices
that
are
incompatible
hardware
revisions
and
they
have
no
way
to
distinguish
them
when
they
ship
them
out.
So
I
accidentally
install
it
on
the
wrong
device,
and
suddenly
I
brick
my
front
door
lock,
no
kidding.
This
happened
not
meant
to
me,
but
anyway
the
so
so
that's
the
first
one.
G
The
second
one
is
two
organizations
in
different
jurisdictions
that
don't
have
overlapping
trademark
rules
happen
to
have
the
same
name
because
they
happen
to
have
the
same
name
and
because
they
use
the
name
to
identify
themselves.
You
suddenly
end
up
with
two
sets
of
two
steps
of
information
that
happen
to
accidentally
overlap
with
each
other.
Now,
admittedly,
this
should
get
picked
up
by
your
by
your
public
keys,
so
that
shouldn't
be
a
problem.
G
There
are
obviously
going
to
be
slightly
bigger
issues
if
you
have
a
infrastructure
where
the
actual
vendor
doesn't
have
the
authority
to
verify
you
or
to
to
install
software
on
your
device,
and
you
have
that
authority,
and
so
you
strip
their
signature.
Add
your
own
and
you're
good
to
go,
and
suddenly
this
problem
comes
back.
So
so
those
are
the
two
scenarios
that
this
is
designed
to
address.
G
I
think
there
is
that
context
actually,
so
this
is
all
being
fairly
naive
when
we're
talking
about
it,
as
we've
talked
about
it
so
far,
the
the
secondary
thing
that
we
haven't
discussed
in
this
context
is
components
with
their
own
vendor
identifiers.
G
G
I
still
have
to
identify
that
it
is
the
correct
one
and-
and
so
this
is
where
the
possibility
of
user
defined
elements
comes
in
that
that'll
show
up
in
you
know,
I
have
a
configuration
file
and
my
configuration
file
has
to
match
my
devices,
so
I
have
to
set
my
devices
to
accept
payloads
that
I
produce
that
have
my
vendor
id
and
and
that's
going
to
be
user
configurable.
Does
that
make
sense.
K
G
And
that
one
might
actually
come
back
to
their
the
there
needs
to
be
two
side
of
the
the
argument
here,
because
asking
every
single
user
to
produce
a
private
enterprise
number
is
probably
a.
C
B
Is
going
to
be
clear,
yeah
I
want
to
make
clear
on
the
the
notes
that,
because
brandon
you
proposed
reusing
like
an
oid,
uuid
and
we'd
still
decide,
is
that
or
do
you
want
to
have
a
brand
new
uuid,
as
I
proposed
I
I
don't
know.
Do
we
come
to
a
conclusion
on
that?
One.
G
B
Space,
no,
the
question
is
whether
the
thing
that
you're
using
after
the
comma,
like
your
namespace
dns
vendor
domain
on
the
top
here
right,
if
that's
yeah,
block
namespace
block,
what's
the
part
on
the
right
side,
is
that
just
a
pen
or
is
that
the
full
oid?
I
think
that's
the
real
question.
B
And
that
means
that
you
have
to
have
the
full
oid
to
compute
it,
and
so
that
means
that
you're
back,
because
I
know
you
had
suggested
it
be
a
list,
not
a
uint
and
I'd
suggested
it
be
aunt.
So
your.
H
H
G
Bytes
representation.
No!
No.
I
realize
that
sorry,
just
let
me
let
me
try
again.
The
vendor
id
becomes
the
pen
or
the
pen
sub
registration,
one
of
the
two
okay.
So
far,
so
good.
B
G
Yeah,
I
I
will
clarify
exactly
what
the
position
is
on
the
list,
but
I'll
say
it
verbally
now.
My
position
is
that
the
the
plan
would
be
the
vendor.
Id
is
an
array
of
uint
or
an
a
byte
string.
One
of
the
two.
B
And
in
cbr
is
it
if
you
have
an
array
of
one
integer?
Is
it
like
one
extra
byte
plus
the
size
of
the
integer?
That's
right
yeah,
so
I
think
that's
fine.
So,
instead
of
let's
say
you
have
a
two
byte
pen,
because
you
just
lots
of
them.
I
think
most
of
them
would
be
one
bite
right
now,
but
so
that
means
your
two.
G
Goes
out,
pennies
are
up
over
fourth
out
or
up
over
sorry,
ten
thousand,
I
think
so
yeah
so
two
bytes
yeah.
So
it
goes
from
two
buys
to
three
bites.
G
Let's
go
on
okay,
so
so
that's
how
you
construct
the
vendor
id
the
class
id,
however,
is
constructed
slightly
differently.
I
will
leave
it
as
it
is
today,
except
that
the
prefix
it
uses
becomes
a
uuid
itself.
That
uuid
is
calculated
from
the
oid
representation
of
the
vendor
id.
B
And
that's
because
we
don't
think
there's
enough
space
savings
to
go
with
the
client
any
type
of
similar
approach
for
class
id.
Is
that
what
you're
saying
again,
I
don't
feel
strongly.
I
haven't
thought
through
the
class
id
part,
because
I'd
only
kind
of
occurred
to
me
during
this
discussion,
so
I
don't
know
if
we
want
to
leave
that
open
or
consider
it
closed.
At
this
point,.
G
C
At
this
point,
I
think
we
need
text
to
yeah
yeah
study,
okay,.
G
G
Okay,
so
these
are
minor
things.
Hopefully
this
won't
take
us
too
long,
so
the
suits
currently
broadly
reserves
negative
numbers
for
customization
without
requiring
any
standards
or
iana
registration.
There
was
a
question
earlier
on
about
whether
we
should
change
this.
I
think
I'm
reasonably
happy
with
the
way
it
is
if
anyone
objects.
G
Yes,
I
do,
but
I
think
that
that
is
should
be
largely
covered
by
the
multiple
manifest
processors
section
of
the
current
draft.
So
the
idea
there
is
yes,
it's
fine
to
have
conflicting
customizations,
provided
that
each
customizer
provides
their
own
parser.
B
B
I
don't
know
if
there's
anybody
else
in
queue
hearing
nothing.
My
question
is:
can
you
do
something
like
say
that
the
interpretation
of
the
negative
numbers
is
driven
by
the
manifest
vendor
id
and
so
every
vendor
id
for
its
manifest?
It's
it
creates
what
the
meaning
of
a
particular
negative
number
number
is
and
say:
that's
who's,
authoritative,
for
it.
G
G
Okay,
any
other
comments
on
that.
G
C
G
C
H
C
Jim,
can
you
put
whatever
you
wanted
to
say
into
the
jabber.
G
Yes,
I
guess
this
actually
raises
a
bigger
question,
which
is:
should
we
allow
this
at
all
now?
I
think
that
there's
a
good
reason
to
allow
some
customization
by
vendors,
but
this
does
introduce
a
situation
where
intermediate
systems
have
no
idea
what
these
mean
and-
and
that
is
of
course,
a
a
question
as
to
whether
that
is
a
good
thing
or
not.
B
When
so,
I
think
jim
is
asking
whether
the
negative
number
should
be
scoped,
not
just
the
vendor
id,
but
the
vendor
id
class
id.
Even,
I
think.
B
About
the
intermediaries
I
mean
an
intermediary
could
always
choose
to
say:
well,
I'm
going
to
disallow
such
manifests,
even
if
they
were
legal.
C
G
Yeah,
I
think
I
think
you're,
correct
and
and
on
top
of
that,
the
other
thing
that
should
probably
happen
is
that,
since
the
common
section
is
required
to
contain
vendor
id
class
id
checks,
then
the
common
section
should
prohibit
any
negative
numbers
in
it
and
that
guarantees
that
they're
scoped
before
an
interpreter
hits
any
of
them.
C
G
That
sounds
like
an
excellent
hackathon
project.
I
look
forward
to
it.
G
Okay,
so
I
it
sounds
like
we're
reasonably
happy
with
that.
G
Okay,
so
the
second
one
I
alluded
to
this
earlier,
especially
in
the
hackathon
report.
Oh
sorry,
we're
still
on
that
previous
slide.
Thank
you.
Some.
We
lack
a
way
to
specify
some,
but
not
all
components.
Previously
a
component
index
was
an
integer
or
a
boolean.
What
I'm
suggesting
here
is
that
we
make
it
an
integer,
boolean
or
array
of
units,
and
the
idea
here
is
that
if
we
make
that
choice,
then
it's
possible
to
set
the
component
index
to
target
more
than
one
component
at
a
time.
G
So
if
there's
any
commentary
on
that,
I
I
think
this
is
probably
the
right
answer.
So
that's
that's
my
opinion
on
it.
If
there's
any
commentary
on
it,
I'd
love
to
hear.
G
G
Hearing
none
shall
we
move
on
next
slide,
please.
So
there's
a
the
this
minor
question.
The
first
one
actually
comes
out
of
the
previous
topic,
and
the
question
is:
would
it
be
better
to
separate
conditions
from
directives
in
positive
versus
negative?
I
think
the
answer
here
is
probably
no,
because
it
would
fall
forward
on
two
parameters
as
well,
and
the
reason
for
this
is
that
currently
conditions
and
directives
align
with
their
parameters
as
much
as
possible
so
that
they
have
the
same
numbers
that
wouldn't
be
as
easy
to
maintain.
G
So
I
I
the
authors,
talked
about
this
and
we
have
no
strong
opinion
on
it.
My
inclination
is
to
leave
it
as
it
is.
G
The
the
one
argument
in
favor
of
it
was
essentially
that,
because
conditions
are
defined
as
having
no
side
effects,
other
than
aborting
and
directives
are
defined
as
having
side
effects,
either
in
the
parameter
space
or
in
the
device
as
a
whole.
Being
able
to
distinguish
them
with
a
clean
line
might
be
helpful.
Having
discussed
this
with
other
implementers
of
the
parser,
they
did
not
feel
like.
There
was
a
large
savings
to
be
had
in
the
parser.
G
G
So
the
examples
are
really
big.
I'd
like
to
try
and
address
that
one
of
the
things
that
they've
got
is
a
lot
of
repeated
hex
printed
byte
strings.
I
don't
think
that
adds
anything
to
the
examples.
So
what
I'm
suggesting
is
that
breaking
from
the
the
formatting
that's
used
in
the
cozy
document,
which
is
what
this
was
originally
modeled
on,
I'm
suggesting
that
wherever
something
is
wrapped
in
a
byte
string,
we
simply
print
that
it's
wrapped
in
a
byte
string
as
displayed
on
the
right
hand,
side
and
eliminate
the
redundant
hex.
F
Yes,
we
can
there.
There
is
a
new
diagnostic
notation
for
do
specifically
for
doing
this,
that
you
can
find
in
the
cddl
document
on
all
right
eliminates
that
it
eliminates
that
first
text
dump
and
says
this
is
this
is
wrapped
in
hex
right.
This
is
wrap.
This
is
the
wrapped
stuff.
G
G
I
think
that
cleans
that
one
up
nicely
next,
please
all
right.
Do
we
have
enough
to
support
teep?
Is
there
anything
that
we're
really
missing
for
supporting
t?
Now
we
we
had
a
list
of
of
requirements
from
teep
and
they
were
first
ta
ids
and
we
we
discussed
that,
and
we
came
to
the
conclusion
that
we
could
do
that
with
component
ids
and
that
we
could
specify
lazy
creation
of
of
security
or
the
security
domains,
and
that
would
solve
teaps
requirements
for
ta
ids.
G
The
second
requirement
was
that
we
need
tam
uris
and
the
conclusion
that
we
came
to
on
that
was
that
suit
supports
uris,
already
and
uri
lists,
and
between
those
two.
We
should
be
able
to
to
satisfy
tape's
requirements,
and
we
also
had
a
question
about
personalization
data
and
the
argument
there
was
that
a
dependent,
manifest
could
specify
personalization
data
and
its
dependency
could
specify
the
the
actual
ta,
and
so
we
believe,
as
the
suit
authors,
that
we
have
what
we
need
to
support
teep.
But
I
would
like
any
feedback
from
the
chief
representatives
here.
B
Them
this
is
dave
I'll
comment
on
that
one.
I
I
don't
have
enough
information
to
say
that
the
answer
would
be
no.
So
the
answer
might
be
yes
now
not
on
the
slide,
but
you
said
it
verbally
brennan
about
you
know
the
implicit
creation
of
security
domains
based
on
a
component
id
there's
also
in
teep
we'd,
have
to
make
some
assumption
about
how
you
ever
delete
a
security
domain,
and
so
you
could
say,
there's
implicit
deletion.
B
B
Right,
so
how
do
you
do
garbage
collection,
because
there's
no
explicit
delete
directive
right,
and
so
you
can
ask
the
same
thing
in
component
ids
on
a
normal
device
is
the
implied
behavior
that
the
container
gets
deleted
whenever
you
use
your
garbage
collection
right,
when
the
last
can,
when
the
last
piece
in
a
container
goes
away,
then
you
delete
the
container.
Is
that
just
the
implied
use
of
component
ids
in
general?
B
B
Dynamically
instantiated
containers
at
any
because
your
component
is
just
an
array
of
you-
know
a
nested
set
of
stuff
right.
G
Yeah,
I
think
we
should
probably
handle
that
more
explicitly
and
the
the
notion
of
going
away
of
explicit
deletion
has
a
lot
of
security
implications
that
that
I
would
be
uncomfortable
dealing
with
without
some
more
discussion
on
on
the
list
on
exactly
how
we
handle
explicit
deletion.
I
think
implicit
deletion
and
leaving
it
up
to
the
agent
on
device
is
a
much
safer
approach,
but
handling
dynamically
instantiated
containers
is
going
to
require
a
little
bit
of
thinking
through
on
that.
I
think.
G
Yeah,
so
I
mean
there
are
two
approaches
to
that
in
in
suit
today.
The
first
is
that
you
instantiate
the
new
one
with
the
same
component
id
as
the
old
one,
and
it
just
replaces
it
and,
and
that's
usually
the
intent.
The
other
option,
I
suppose,
would
be
to
replace
it
with
a
zero
size
payload,
which
should
be
the
closest
we
currently
have
to
explicit
deletion.
B
Yeah,
I
think
the
that's
the
one
that
we'd
have
to
explicitly
point
out,
because
there
are
cases
in
teep
where
you
can't
use
the
same
component
id
because
the
quantum
id
might
be.
You
know
the
actual
hash
of
the
ta
or
something
that's
specific
to
the
teep
security
purpose.
You
can't
just
replace
one
ta
with
another
ta,
it's
a
different,
a
different,
unique
identifier
right
so
replacing
with
zero
content,
or
something
like
that.
B
G
I
think
it's
worth
calling
that
out
and-
and
I
mean
since
we
can
do
that-
I
I
think
I
can
safely
say
that
we
do
not
have
a.
We
do
not
have
a
requirement
to
introduce
an
explicit
deletion
because
we
already
have
a
mechanism
to
handle
it
right
yeah.
It
may
be
worth
saying
that
this
could
be
done.
That's
why
there's
no
yeah.
B
The
other
thing
that
came
up
in
a
teep
was-
and
this
had
to
do
with
my
some
of
my
when
I
was
discussing
where,
like
a
teep,
specific
template
and
example-
go
which
would
be
in
the
teep
document
and
doing
that.
We
want
to
make
sure
that
the
existing
directives
are
sufficient
to
be
able
to
handle
the
case
where
you've
already
got
the
binary
cash
locally,
and
you
want
to
get
permission
to
install
it.
And
so
that's
the
one
that
I
don't
know
if
there's
any
gaps.
B
G
B
H
So
great
so
dave
and
brandon,
this
is
dave
just
a
couple
of
quick
questions
on
this,
so
you
know,
I
think,
just
as
far
as
our
strategy
here,
it's
possible
that
these
sorts
of
issues
will
keep
coming
up
over
time.
We
do
have
ayanna,
you
know,
registration,
you
know,
capabilities,
you
know
for
some
of
these
things
right.
So
my
question
is:
at
what
point
do
we
sort
of
cut
off
this
discussion
and
publish
the
manifest
draft
versus
you
know?
H
How
long
do
we
wait
until
we
feel
like
we've,
you
struck
a
right
balance.
Any
any
commentary
on
that.
B
Well,
to
dave
to
your
point:
there
could
be
another
working
group
that
starts
using
it
and
we
won't
know
about
that
until
later,
and
so
I
I
wouldn't
wait
per
se.
I'd
get
in
whatever
is
within
the
time
frame
that
we
have
for
the
suit
manifest,
but
we
shouldn't
hold
it
for
that,
because
it
could
always
be
on
a
separate
document.
H
G
Your
presentation,
so
then
I
only
have
one
slide
left.
So
do
we
have
enough
to
support
rats
so
this
this
came
up
previously.
There
was
a
question
about
reporting
policy,
so
the
idea
here
with
reporting
policy
was
effectively
that
you
could
use
the
unused
null
at
the
end
of
many
commands
to
encode
what
you
should
do
once
that
command
has
been
executed,
and
so
we've
put
in
a
proposal
for
that.
G
I
think
this
is
adequate
to
be
able
to
encode
attestation
policy
and
reporting
policy
inside
the
manifest,
which
gives
us
dynamically
updatable
policies,
which
is
kind
of
a
neat
feature.
Now
these
are
hints
they
aren't
mandatory,
so
the
the
reporting
engine
can
always
override
them,
but
this
is
what
it's
provided
with
as
in.
Please
send
me
this
or
please
don't
send
me
that
I
think
this
is
enough
to
support
rats.
G
As
far
as
I
understand
from
the
folks
in
rats,
this
should
be
enough
to
support
rats.
So
it's
just
the
question:
do
we
have
enough
and
following
dave's
comment
previously,
we
should
probably
not
wait
too
long
to
work
that
out.
B
I
think
this
question
is
separate
from
the
question
of
the
reports
themselves,
but
this
is
about
what
goes
in
no
bite
and
so
on,
and
so
right.
G
G
So
I
think
we're
pretty
good
on
this.
I
should
reiterate
that
we're
only
using
four
bits
and
because
we're
only
using
four
bits,
it
fits
in
exactly
the
same
size
as
the
null
byte,
but
because
it's
a
bit
field,
we
can
expand
it
if
needed
at
some
later
time.
B
Well,
there's
another
question:
she'd
have
a
slide
on
which
was
should
the
actual
report,
information
itself,
which
does
not
appear
in
the
manifest,
should
that
be
factored
into
a
separate
draft,
which
is
what
I
was
saying.
Yes,.
G
So
you
you
believe
it
should
be
factored
into
a
separate
draft.
I'm
totally
fine
with
that.
If
anyone
else
has
a
comment,
I
guess
well,
I
guess
if
the
chairs
are
saying
factor
it
into
another
document,
it's
pretty
clear.
I
was
saying
that
as
an
individual.
B
I
don't
know
what
the
other
chairs
think.
So
all
right.
My
rationale
is
that
the
report
stuff
is
brand
new.
The
report
stuff
assumes
that
you
are
using
rats,
and
so,
if
you
might
want
to
clean
compliance
to
one
but
not
the
other,
and
it
gives
us
more
time
to
iterate
on
the
report
stuff
should
we
need
to
and
while
still
put
it
getting
the
manifest
done
soon.
So
that
was
our
rationale
for
putting
it
and
because
the
manifest
document,
then,
is
nice
and
clean.
B
G
That
seems
like
a
reasonable
rationale:
let's,
let's
strip
it
out
and
put
it
in
another
draft.
It's
gonna
be
a
very
short
draft,
but
that's
probably
fine.
B
Well,
we've
talked
about
potentially
having
up
to
four
other
drafts.
That's
come
up
in
this.
In
today's
discussion,
we've
talked
about
whether
capability
reporting
gets
put
into
a
separate
draft,
whether
this
part
gets
put
into
a
separate
draft
yep
the
mud
stuff
that
you're
going
to
talk
about
in
a
minute
and
then
whether
we
have
a
suit
v2
in
the
future.
Those
are
the
four
possible
drafts.
We've
talked
about.
B
Trying
to
find
the
correct
screen,
because
this
was
the
suit
mud
all
right.
Let
me
just
bring
it
up
here.
I
thought
I
headed
up.
Oh
it's
probably
in
there
we
go
there.
It
is.
G
Okay,
so
this
one
hopefully
will
be
quite
quick,
so
this
was
what
we
presented
to
sec
dispatch
previously,
this
was
raised
on
the
list
and
the
suit
chairs
wanted
dispatch
to
have
a
look
before
we
before
we
adopted
or
sorry
before
we
discussed
it
in
suit.
So
what
this
is
effectively
next
slide.
Please
is
an
attempt
to
answer
the
question
who
gets
to
define
what
your
device
does
when
it's
on
your
network.
Next,
please
so.
G
Mud
is
a
a
document
format,
primarily,
but
also
a
workflow
for
defining
what
your
device,
what
kind
of
firewall
rules
your
device
needs.
Mostly,
there
are
a
few
different
ways
to
report
it.
Some
of
them
are
unauthenticated.
I
don't
think
we
should
really
talk
about
those
too
much.
Some
of
them
are
authenticated,
but
they
take
802.1x
to
do
the
authentication,
which
of
course,
is
slightly
more
limiting.
G
Not
everyone
has
an
802.1x
network,
the
service
hosting
a
mud
url,
which
is
how
the
documents
are
reported,
effectively
gains
the
ability
to
set
network
policies
on
your
network
so
because
of
that
it
requires
an
audit
and
rfc
8520
actually
calls
out
that
you
probably
need
to
verify
web
trust
on
the
the
holder
of
the
signature
keys.
Next,
please.
G
So
there
are
some
complexities
here.
If
you're,
not
using
802.1x
a
device
could
arbitrarily
report
the
wrong
url,
as
could
anyone
else
on
your
network.
G
The
server
hosting
the
mud
url,
of
course
requires
a
an
audit
and,
and
as
a
result
of
that,
there's
the
mud,
signature,
that's
proposed
and
rfc
8520
also
calls
out
that
a
rogue
ca
can
authorize
a
mud
signer
and
then
they
that
mud
signer
gains
the
ability
to
set
policy
on
your
network
and
device.
Communication,
of
course,
can
be
altered
by
configuration,
which
raises
the
question
of
whether
you
need
multiple
mud
urls
for
a
single
device
or
a
single
class
of
devices.
G
G
Then
the
idea
here
is
that
any
of
these
entities
could
specify
a
mud
file
explicitly
or
authorize
a
signer
for
mud
files.
Next,
please!
G
So.
The
idea
here
is
that,
if
your
suit
manifest
contains
a
mud
file
or
a
or
a
delegation
like
the
hash
of
a
public
key
of
the
signer,
you
want,
then
you're
able
to
or
and
the
uri
then
you're
able
to
delegate
with
a
an
explicit
chain
of
trust
that
goes
back
to
the
manifest
signer
and
from
there
back
to
the
root
of
trust.
G
We
could
deliver
either
the
whole
mud
file
or
a
mud,
url
or
a
trust
anchor
for
a
mud,
signature
or
any
combination,
though
some
of
those
don't
make
sense,
and
the
idea
here
is
that
we
would
also
define
a
few
claims
for
rats
so
that
we
would
be
able
to
attest
certain
values
that
would
simplify
complexity.
Now.
This
is
an
interesting
result,
because
it
allows
the
mud
manager
to
be
a
relying
party.
G
The
mud
manager
can
do
attestation
or
sorry
can
verify
attestation
reports
of
a
device
and
then
recommend
policies
to
network
infrastructure
for
those
devices,
and
that
allows
much
more
strict
correspondence
between
an
individual
device
and
the
network
policies
applied
to
it.
Next,
please,
or
is
that
it
advantages?
Yes,
there
are
fewer
actors,
you
don't
have
to
audit,
both
the
mud,
signer
and
the
firmware
vendor.
H
C
I
think
the
question
is:
do
we
want
to
do
a
recharter
to
bring
this
in
and
let's
take
that
to
the
the
mail
list.