►
From YouTube: IETF100-SUIT-20171113-1550
Description
SUIT meeting session at IETF100
2017/11/13 1550
https://datatracker.ietf.org/meeting/100/proceedings/
A
B
C
Okay,
if
you're
sitting
here
looking
for
something
to
do,
we
are
still
in
need
of
a
jabber
strive
and
still
in
need
of
a
second
note-taker.
So
is
there
anybody
here,
that's
going
to
be
in
the
jabber
room,
they'd,
be
willing
to
monitor
the
jabber
I'm
here,
okay,
thank
you.
We
have
one
note-taker
right
now.
Can
we
get
a
second
note-taker,
so
we
have
an
etherpad.
C
The
link
is
up
there,
but
it's
a
regular
anything
that
pad
to
the
session,
and
so,
if
we
get
two
people
to
be
updating
the
etherpad,
is
there
a
second
person
that
would
be
willing
to
watch
the
etherpad
or
send
us
their
own
notes?
Afterwards?
Don't
care
which
note-taker
volunteer,
note-taker
volunteer?
You
know
we
already
have
one
and
when
you've
seen
a
backup,
note-taker.
B
B
B
The
goal
of
suit
is
to
standardize
software
update
capabilities
I'm.
One
of
our
primary
goals
for
this
effort
is
as
to
come
up
with
something
that
will
work
with
constrained
devices,
we're
specifically
trying
to
target
class.
One
constrained
devices
that
have
10
kilobytes
of
RAM
and
around
a
hundred
kilobytes
of
flash
by
capability.
B
Okay,
so
we're
we're
working
on
fixing
the
AP
so
that
the
slides
also
show
up
on
me
deco,
so
just
bear
with
us
a
moment.
The
blue
sheets
are
on
their
way
around.
We,
we
have
a
couple
of
note:
takers,
Tim,
pulk
and
and
Mike
Rosa
have
both
offered
to
take
notes
for
this
session
and
Stephen
Peng
heart
will
be
in
the
jabber
room
as
our
Java
jabber
scribe.
So
thank
you
to
to
all
of
you
for
volunteering
to
help.
B
B
B
B
This
is
our
agenda
for
today.
So
we're
going
to
focus
on
I'm
going
to
do
a
read
of
the
proposed
charter
text.
Then
we're
going
to
have
what
we're
hoping
to
be
around
a
45-minute
charter
discussion.
If
we
end
up
going
along
we're
going
to
focus
on
on
the
Charter
instead
of
some
discussion
of
some
new
work
items
and
then
we're
going
to
wrap
up
the
meeting
with
a
quick
review
of
our
proposed
milestones
and
talk
about
next
steps,
any
agenda
bashing.
B
Okay,
I
already
talked
about
this.
We
we've
dealt
with
that
okay,
so
Charter
Review,
so
we've
had
lots
of
conversation
on
the
Charter
over
the
last
few
months
since
I
ATF
99,
it
seems
like
most
of
the
focus
has
been
on
a
fairly
narrow
portion
of
the
Charter
text.
So
we're
going
to
be
talking
about
that
in
a
little
bit.
B
The
Charter
so
far
has
been
through
internal
review.
With
you
know,
initial
is
G
and
IAB
reviews
we've
gotten
some
feedback
on
that.
Currently,
it's
scheduled
for
currently
the
the
process
of
external
review
has
started
on
the
Charter
and
it's
scheduled
for
the
11:30
tell
a
chat
so
we're
hoping
I
get
the
Charter
wrapped
up
fairly
quickly,
so
that
so
the
things
can
progress.
B
So,
during
this
review
of
the
Charter
text,
there's
a
few
things
that
that
we
want
you
to
to
focus
on.
Primarily
we
want
to
know
that
the
the
Charter
text
is
clear
or
not,
and
we
want
to
work
to
clarify
any
any
concerns
with
the
Charter.
We
want
to
know
if
the
Charter
captures
and
accurately
the
work
that
is
being
proposed
and
we
want.
B
We
want
to
make
sure
that
it's
work
that
we
can,
we
can
move
on
fairly
quickly.
One
of
our
goals
for
this
this
proposed
effort
is
to
is
to
produce
something
in
a
fairly
short
amount
of
time,
so
that
we
can
influence
software
updating
capabilities
in
the
industry.
So
one
of
the
things
that
that
we
would
like
to
not
focus
on
for
this
initial
effort,
I'm
is
to
define
a
transport
protocol
for
exchanging
software
updates.
B
E
B
B
B
The
discussion
that
we've
had
to
date
is
largely
focused
on
the
fact
that
we
don't
want
to
further.
We
don't
want
to
create
yet
another
transport
solution
I'm
in
this
space.
The
one
thing
that
has
been
missing
through
a
lot
of
the
current
efforts
is
is
a
solution
that
would
provide
the
capabilities
of
a
manifest
format,
and
so
the
discussion
has
really
been
around
trying
to
focus
on
on
those
aspects.
G
E
So
this
is
like
you
with
your
your
your
proponent
hat
on
just
it's
just
like
it
was
a
little
bit
unclear
when
you
when
you
say
that
it's
like,
and
this
is
a
little
bit
of
a
novel
process
as
well,
because
there's
AB
off,
but
the
Charter
is
already
out
for
external
review,
so
I
just
wanted
to
understand.
It's
like
this.
Is
you
and
your
your
personal
opinion
is
that
this
is
what
we
are
not
going
to
do
as
opposed
to
some
other
version
of
we.
H
Okay,
so
I
want
to
ask
about
this:
defining
a
new
transport
versus
selecting
one,
that's
using
what
many
people
have
proposed.
So
a
big
group
of
wheat
me
that
does
not
seem
to
be
the
same
is
that
we
good
that
the
most
important
and
exactly
she
taught
me
how
the
interoperability
group
between
a
advice,
its
firmware
skirt,
and
that
there's
several
transport
protocols
that
are
used
there
and
that
our
architecture,
in
fact,
I,
believe
the
current
Charter.
That's
before
the
the
is.
H
C
I
think
this
is
a
Dave
speaking
from
jerk
I
believe
the
discussion
is
that
defining
a
new
transport
or
a
transfer
protocol
as
out
of
scope,
but
discussion
of
use
of
existing
ones
and
how
you
might
use
them
without
changes
is
in
scope
and
I
see
Dave
Walter
I'm,
not
not
it.
So.
Does
that
answer
your
question
coming?
Yes,.
B
Okay,
so
so
I'd
like
to
move
on
since
we're
short
on
time
to
discussion
of
the
Charter,
so
I'm
the
read
through
the
Charter,
please,
if
you
have
constructive
comments
about
changes
to
the
Charter,
let's,
let's
hold
those
until
we
actually
get
to
the
discussion
portion
of
this
focus.
Only
on
clarifying
questions
relating
to
the
Charter,
please
so
the
Charter
says
vulnerability
is
an
internet
of
things.
Devices
has
raised
the
need
for
a
secure
firmware,
update
mechanism
that
is
also
suitable
for
constrained
devices.
B
Security
experts,
researchers
and
regulators
recommend
that
all
IOT
devices
be
equipped
with
such
a
mechanism.
But
there
are
many
proprietary
firmware
update
mechanism
mechanisms
in
use.
Today
there
is
a
lack
of
a
modern,
interoperable
approach
to
securely
updating
the
software
and
I
have
T
devices.
A
firmware
update
solution
consists
of
several
components,
including
a
mechanism
to
transport
firmware
images
to
IOT
devices
the
manifest
that
provides
metadata
about
the
firmware
image,
such
as
a
firmware
package
identifier.
B
The
hardware
of
the
package
needs
to
run
on
run
dependencies
on
other
firmware
packages,
as
well
as
cryptographic,
information
for
protecting
the
firmware
image
in
an
end-to-end
fashion,
from
our
image
and
and
also
a
solution,
consists
of
with
the
firmware
image
itself.
So
RFC
4108
defines
a
manifest
format
today
that
uses
the
cryptographic
message
syntax
to
protect
firmware
package
packages,
so
more
than
ten
years
have
passed
since
the
publication
of
RFC
4108
and
greater
experience
with
IOT
deployments
has
led
to
additional
functionality
requiring
the
work
done
with
RFC
4108
to
be
revised.
B
This
group
will
focus
on
defining
a
firmware,
update
solution
for
class
1
devices
and
as
defined
in
RFC
72
28,
that
is
IOT
devices
with
roughly
10
kilobytes
of
RAM
and
roughly
a
hundred
kilobytes
of
flash.
The
solution
may
apply
to
more
capable
devices
as
well.
This
group
will
not
define
any
transport
mechanisms.
A
June
of
2016,
the
internet
architecture
board
organized
a
workshop
on
Internet
of
Things
software
updates,
which
took
place
at
Trinity
College
in
Dublin
Ireland.
B
The
main
goal
of
the
workshop
was
to
foster
a
discussion
on
requirements,
challenges
and
solutions
for
bringing
software
and
firmware
updates
at
IOT
devices.
This
workshop
also
made
clear
that
there
are
challenges
with
misaligned
incentives
and
complex
value
chains.
It's
nevertheless
seen
as
important
to
create
standardized
to
create
standard
building
blocks
that
help
interested
parties
implement
and
deploy
a
solid
firmware
update
mechanism.
I
can
pause
there
for
a
question.
Yeah.
I
B
I
believe
the
assumption
is
yes.
Thank
you
so
continuing
on
with
the
Charter
in
particular,
this
group
aims
to
publish
several
documents,
namely
an
IOT
for
a
more
update
architecture
that
includes
a
description
of
the
involved
entities,
security
threats
and
assumptions,
and
also
one
or
more
manifest
format
specifications.
So,
we've
had
a
couple
of
interesting
discussions
on
the
mailing
list,
focused
around
some
text
on
what
the
initial
work
of
this
working
group
will
be
I'm,
going
to
read.
B
B
So
the
first
paragraph,
which
is
the
text
on
the
data
tracker
states
that
the
initial
focus
of
this
group
will
be
development
of
a
manifest
approach
based
on
CMS
and
the
asn.1
encoding.
This
work
will
result
in
a
revision
to
RFC
4108
that
reflects
the
current
best
practice
practices.
Use
of
the
asn.1
encoding
is
desirable
due
to
existing
as1
support
in
crypto
libraries
used
within
current
IOT
operating
systems.
The
group
may
later
adopt
alternate
manifest
formats
using
other
serialization
approaches,
for
example,
see
Bor.
B
B
Scroll
down
so
then
the
Charter
continues
by
saying
this.
This
group
does
not
aim
to
create
a
standard
for
a
generic
software
update
mechanism
for
use
by
rich
operating
systems
like
Linux,
but
instead
this
group
will
focus
on
software
development
practices
in
the
embedded
industry.
Software
update
solutions
that
target
updating
software
other
than
the
firmware
binary.
For
example,
updating
scripts
are
also
out
of
scope.
The
group
will
aim
to
maintain
a
close
relationship
with
silicon
vendors
and
OEMs
that
develop
IOT
operating
systems,
so
I'm
any
clarifying
questions
on
the
Charter.
J
Hoffman,
so
this
is
not
about
my
text.
This
is
about
something
else,
but
it
sort
of
feeds
into
this
RFC
4108
seems
to
take
up
a
big
place
in
this
that
this
is
for
revising
at
subject.
I'm,
not
sure
that
that's
at
all
appropriate.
The
IO
TSU
workshop
barely
talked
about
4108
4108
is
a
format
that
is
standardizing
the
IETF,
but
it
wasn't
done
in
a
working
group.
I
mean
it
had
plenty
of
input,
a
bunch
of
us
in
the
room.
J
Actually,
you
know
we're
part
of
that
yeah,
but
that
doesn't
seem
like
a
good
place
for
starting
just
because
it
exists.
So
I
would
suggest
that
we
might
also
consider
taking
out
anything
about
4108,
especially
because
the
early
work
that
we're
seeing
isn't
4108
ish
and
it
doesn't
have
the
same
properties
that
4108
even
said
about
itself.
So
I'm,
you
know
in
case
other
people
are
saying:
oh,
but
4108
is
this
or
that
I'm
not
sure
that
we
want
to
nest
thoroughly,
have
a
focus
on
them
right.
I
I
B
I
K
L
Eric,
not
mine,
so
falling
on
to
what
allowance
saying
that
yeah
I
think
that
people
are
what
what
seem
4108
and
I'm,
which
I
think
applies
more
generally.
Is
you
have
multiple
pieces
of
firmware
because
it's
the
soft
radio,
that's
a
separate
chip,
whatever
right
microcontroller,
and
it
has
a
separate
piece
of
firmware
so
so
I
think
that
that
generalization
is
easy,
a
necessary
one.
I
don't
understand
what
a
script
is.
B
L
What
I
script
this
as
opposed
to
a
piece
of
a
binary
code?
Just
because
of
you
know
whatever
byte
encoding
is
of
something
that
is
Python
as
opposed
to
something
that's
interpreted
by
something
else
which
happens
to
be
the
some
instruction
set.
That
seems
like
a
rather
arbitrary
thing.
I
think
that
the
key
thing
is
that
we
shouldn't.
Actually,
this
is
not
building
a
package
upgrade
update
system
like
we
have
in
traditional
operating
system,
China
or
the
rich
operating
systems,
and
it's
the
fact
that
it
takes
a
small
number
of
pieces
of
software.
L
G
M
This
is
honest:
I
want
to
respond
to
Eric's
question
I
believe
this
was
added
in
response
to
some
email
traffic.
On
the
question
of
whether
the
use
of
JavaScript,
like
dialogues
or
Python,
like
dialogues,
is
in
scope
or
not
and
and
I
believe,
the
confusion
was
in
the
end
that
we
want
to
start
with
something
sort
of
more
restricted
in
scope
than
updating
sort
of
cherry
script
or
micro,
bison
and
so
on
on
those
devices.
N
C
I
heard
I
saw
lots
of
people,
I
should
say:
I
saw
a
number
of
people
arguing
on
the
list
that
there
are
things
in
here
that
they
disagree
with
and
I
haven't,
heard
anybody
picking
on
the
text
or
posed
by
Paul
and
so
so
far
I
think
there
is
okay,
yep
okay
people
in
the
in
the
room,
I'll
go
to
you
in
just
a
second
here
so
far,
I
have
not
yet
heard
arguments
against
Paul's
text
and
so
we're
leaning
towards
a
rough
consensus.
O
N
C
B
A
B
Oh
yes,
yes,
so
I
think
actually
the
next
part
of
the
discussion.
So
one
of
the
things
that
we've
been
talking
about
the
fact
that
there's
a
tip-off
this
week
and
that
there
is
a
potential
relationship
between
the
two
efforts,
so
Maya
Davis,
going
to
have
some
conversation
on
resolving
that
relationship.
B
C
How
do
you
get
code
into
a
trusted
execution,
environment?
Okay?
So
since
it's
very
relevant
to
putting
code
on
things,
that's
kind
of
the
relationship
there?
Okay
now
it
is
also
in
the
category
of
having
a
draft
charter
and
it's
a
working
group
forming
vows
of
the
buff
on
Wednesday
as
I
talked
about
proposed
charter
text.
Okay,
and
so
when
talking
about
the
scope
of
them.
C
So,
okay,
here
we
go
so
if
you
read
the
draft,
the
draft
charter
text
posted
on
the
data
tracker
for
both
groups,
you'll
notice,
there
is
some
overlap.
Okay,
and
so
this
week
is
the
time
for
us
to
clean
that
up
and
and
reflect
whatever
the
community
thinks
is
the
right
relationship
between
those
two.
C
So
if
you
do
a
compare
and
contrast
of
the
current
wording,
not
the
one
that
we
just
edited
right,
but
the
current
wording-
that's
post
on
the
data
tracker
for
the
two,
you
notice
a
couple
of
things
that
are
sort
of
the
compare
and
contrast.
The
first
one
is
that
the
charter
text
for
a
teep
focuses
on
code
of
their
installation
of
code
into
a
trusted
execution
environment,
regardless
of
whether
it's
for
IOT
or
not
okay,
I
mean
size
to
use
cases.
C
Is
there
a
use
case
in
the
non
IO
to
use
case
but
they're
both
sort
of
listed
as
being
in
scope
for
the
tea,
because
it
has
a
trust
attitude
around
okay,
whereas
soot
focuses
on
installation
of
code
into
an
IOT
device,
regardless
of
whether
it's
in
a
te
e
or
not?
Okay,
you
say:
okay,
well,
there's
a
little
bit
of
overlap.
C
If
you
only
look
at
the
first
bullet,
okay,
which
is
if
it's
a
te
e
inside
of
an
IOT
device,
and
it's
in
the
overlap
right,
if
you
were
to
only
look
at
first
bullet
again,
this
is
current
wording.
The
last
questions
ought
to
get
to
is
what
should
the
division
of
labor
be?
What
should
the
text
in
either
of
them
say
and
we'll
have
the
same
discussion
over
in
the
tee
off,
because
if
we
conclude
that
the
suit
charter
is
fine
and
the
TPR
tertex
should
change,
that's
the
Wednesday
discussion.
C
Okay,
second
thing
that
you
notice,
if
you
read
both
of
them,
is
that
the
t
p--
text
talks
about
how
do
you
get
code
there,
the
first
time,
but
doesn't
currently
continue
text
about?
How
might
you
update
it
and
the
suit
text
talks
about
updating,
but
it
doesn't
talk
about
how
it
gets
there,
the
first
time?
Okay,
maybe
that's
by
design.
Okay,
point
is
one
is
talking
about
how
do
I
get
code,
the
first
time
and
suit
talks
about
how
do
you
do
updates
if
things
that
are
already
present?
C
C
This
was
getting
back
the
scripts
question,
okay,
I
think
in
a
side
discussion
we
concluded
that
what
T
focuses
on
is
not
the
stuff
that's
used
to
boot
as
the
stuff
that
might
be
installed
to
run
later
on,
and
so
that's
what
we
mean
by
an
app
and
so
on
a
class-one
device.
There
may
be
no
such
thing,
for
example,
right,
because
all
that
ron's
is
there
is
what
comes
up
at
boot,
whereas
suit
focus
is
on.
Sometimes
it
uses
the
word
software
in
the
Charter
text.
C
Sometimes
it
uses
the
word
firmware
in
the
Charter
text,
and
sometimes
it
uses
software
or
firmware.
So
if
we
were
to
go
back
to
there,
you
do
a
search
through
some
places.
It
says
software
some
place
that
says
firmware
some
places,
it
hasn't
or
okay.
Now
the
proposed
intent
of
what
we
think
that
people
mean
is
that
suit
focus
is
on
the
stuff
that's
used
to
boot,
and
so,
when
we
say
firmware,
we
mean
sort
of
the
piece
of
code.
C
C
Okay,
so
we
can
figure
out
what
the
right
terminology
is,
but
I
think
that
the
intent
at
least
our
understanding
of
those
who
have
commented
on
the
suit
and
teep
stuff
is
that
that
one
is,
we
believe,
disjoint
between
the
two
okay
meetings,
where
the
the
the
OS
like
firmware
versus
the
applications
that
run
on
top
of
it
after
boot?
Okay,
now
maybe
we
can
clean
up
the
language
and
stuff
there,
but
and
the
intent
here
is
not
to
have
a
mic
line
to
talk
about
the
terminology.
C
Unless
there's
some
really
trivial
wording
thing
to
do,
but
I
don't
want
to
that's
not
the
main
focus.
The
main
focus
is:
what's
the
right
scope:
okay,
now
that
you've
seen
these
three
different
things,
how
they
overlap
or
don't
overlap
when
you
put
all
three
axes
together:
okay,
now,
if
we
go
back
to
the
suit
text,
is
there
anything
that
we
should
change
to
make
it
clear
or
about
what
the
scope
is
for
what
suit
should
do
versus
what
teacher
do
if
they're
both
charters,
working
groups?
C
Okay,
so
now
the
question
here
is:
what
should
the
work
split
be,
and
so
what's
the
intent?
Okay,
what
do
you
want
the
intent
to
be
and
then
what?
If
any
changes
do
we
need
to
make
in
the
suit
charter
text
to
reflect
the
intent?
So,
let's
first
talk
about
what
do
we
think
the
intent
is
of
what
shoot
should
do
versus
teach
to
do
so?
I.
L
Think
there's
another
difference
which
you're
not
covering,
which
is
sort
of
what
does
validating
mean
in
these
things
and
I
think
that
that
tip
has
a
more
complex
model
in
that
space
right,
where
there's
more
parties
involved
in
terms
of
who
exactly
signs.
What
and
who
sort
of
is
authoritative
for
what
and
you
might
have
things
like
that
in
suit
as
well.
L
If
if
there
could
be
cases
when
there's
someone
that
signs
the
manifest
so
there's
a
validation
about
again
against
some
sort
of
route
of
trusts,
whatever
security
Association
depending
upon
the
mechanism-
and
you
might
have
a
separate
one
for
the
actual
firmware
you
download,
if
that's
not
part
of
the
manifest
itself,
potentially
right,
but
it's
still
a
lot
simpler
than
I.
Think
what
what
what
keep
is
trying
to
do
so
I
think
it
might
make
sense
to
fly
that
as
one
of
the
differences
as
well
and
then
saying.
C
I
know
among
the
cheap
proponents,
there
is
a
thing
and
the
teeth
list
was
mentioned:
gee,
it
sure
would
be
nice
if
we
could
maybe
share
some
of
some
of
the
things
that
suit
is
doing
or
Mike
do
might
be
applicable
to
us.
So
maybe
a
manifest
format
or
something
who
knows,
but
that's
really
for
teeth
to
discuss
as
to
how
much
of
suit
stuff
would
be
relevant
to
them.
But
they
don't
want
to
reinvent
stuff.
That
would
be
in
suit
if
it
were
reusable,
but
right
now
it's
unknown
whether
something
would
be
reusable
honest.
M
M
You
agree-
maybe
maybe
the
language,
for
example,
suit
as
we
changed
the
terminology
after
or
the
name
of
the
work
of
this
effort.
Maybe
wasn't
that
appropriate,
because
it
talks
if
it
gets
leaves
the
impression
that
it's
more
generic
than
it's
actually
supposed
to
be.
Certainly.
M
In
in
in
case
of
deep
when
he
was
proposed
in
Chicago
at
the
BOP,
it
was
the
primary
use
case
back
then,
and
still
is
the
use
of
in
smart
phones
India.
If
you
look
at
the
Charter
that
we
just
David
just
read,
it
talked
about
the
real
world
and
a
normal
operating
system
versus
sort
of
IOT
operating
systems
and
in
a
for
example,
in
a
trust
zone
based
EE.
We
actually
talking
about
two
operating
systems.
M
They
are
not
just
one
one
big
one
like
Linux,
but
also
another
one,
a
real-time
operating
system,
so
that
would
be
a
bigger.
But
of
course
the
IOD
terminology
is
it's
often
very
confusing,
but
you
have
to
put
it
there
in
the
Charter
somewhere
to
attract
the
right
audience.
But
IOT
has
such
a
wide
notion
that
some
people
refer
to
mobile
phones
as
IOT
and
some
people,
not
so
so
that
makes
it
makes
it
a
little
tricky.
M
C
Q
To
clean
up
our
language,
software
Briss
versus
firmware,
and
things
like
that
also
agree
with
haniss,
and
that
we
need
to
be
careful
to
actually
use
the
IOT
lingo,
because
these
are
the
people
we
need
to
talk
to
now.
I
had
one
specific
comment
about
what
they
said
with
this
focusing
on
like
this
boot
differentiation
I
think
it's
a
it's
a
it's
an
it
could
be
a
nice
differentiator
with
teep.
Q
But
if
we
look
at
the
the
actual
solutions
that
are
currently
developed
for
firmware
updates,
the
bootloader
aspect
is
completely
different
from
the
image
and
might
create
a
you
know:
a
wrong
impression
that
you're
actually
updating
the
whole
binary.
That's
working
on
the
device,
including
the
bootloader,
which
is
actually
not
the
case,
so
I'm
not
sure
how
you
know
if
we
can
really
use
this
aspect
of
booting
as
as
easily
as
as
you
suggest
it
to
differentiate
that.
N
So
so,
here
on
this
question,
I
really
like
the
way
you
boiled
it
down
and
for
me
it
also
comes
down
a
little
bit
to
on
the
the
exact
Charter
that
we're
talking
about
in
suit.
So
isn't
the
manifest
like
the
contents
we're
going
to
put
in
the
manifest
like?
Is
this
the
first
topic
here
and
if
it
is?
Maybe
it
is
something
that
cheap
people
can
just
say?
Okay?
Well,
you
know
these
all
these
things
that
the
suit
thinks
that
the
suit
guys
defined
in
their
manifest.
N
Well,
maybe
we
should
support
it,
and
you
know,
and
in
future
versions
they
see
exactly
how
these
two
relate
to
each
other
I
mean
I
I
like
very
much
this
separation
between
apps
and
firmware.
You
know,
but
this
is
like
going
down
into
exactly
how
the
process
is
going
and
so
forth,
but
if
we
are
limited
to
the
manifest
file
and
say
okay,
you
need
this
information
and
you
get
something
that
has
some
cryptographic
information
assigned
to
it
from
this
place.
N
B
C
So
far,
I've
heard
support
for
changing
some
language,
potentially
in
the
suit
chart,
so
focus
on
feedback
for
suit,
as
opposed
to
feedback
for
chief,
where
potentially
changing
some
language.
Regarding
the
third
bullets
about
no
software
versus
firmware,
and
maybe
updating
the
language
there
somehow
to
reflect
the
intent
which
I
think
people
I
her
positive
feedback
about
the
intent
of
the
third
bullet.
I
think
people
tend
to
agree
with
the
the
way
that
we
talked
about
it
before.
C
I
did
not
hear
anybody
arguing
that
the
suit
Charter
needed
to
change
any
way
to
address
anything
in
the
first
or
second
bullet.
The
chief
charter
may
need
be,
but
what
I've
heard
is
that
if
you
update
the
third
bullet
nobody's
asking
for
any
changes
after
the
third
bullet
changes,
because
there's
already
a
division
of
labor
between
there,
whether
there
sounds
like
there's
any
overlap
on
the
first
two
bullets
is
not
as
important
because
the
distinction
is
on
the
third
bullet.
That's
what
I've
heard
so
far.
I've
got
that
wrong.
C
Let
me
know
because
otherwise
that's
what
I
see
is
kind
of
the
emerging
feedback
from
the
room.
So
unless
there's
any
are
comments
on
that,
then
let's
go
to
the
jabber
queue.
Yes,
yeah!
That's
what
we're
gonna
go
to
the
jabber
queue
neck.
So
whoever
is
a
jabber
scribe.
Please
come
up
going
to
meet
echo.
Oh
thank
you.
Sorry
I
thought
you
said.
Jeff
David
go
ahead.
Yes,.
O
G
O
L
C
A
class
one
device
it
might
be
that
the
whole
thing
is
the
trusted
execution
of
our
mind.
There
is
no
untrusted
execution
environment,
so,
in
other
words,
there
can
be
different
types
of
class,
one
devices
and
you're
right
trust
last
one
might
not
be
separate,
but
it
doesn't
mean
that
they
wouldn't
necessarily
have
a
Trust
Act
use
environment.
C
But
the
third
bullet
on
here
is
the
one
that
says
What's
in
scope,
for
which
one
at
least
from
what
we're
talking
about
right
now:
okay,
which
is
if
you're
talking
about
a
class
one
to
buy
it,
only
has
a
truss
execution
arm
and
that's
the
firmware
that
would
be
in
suit,
but
might
actually
entail
some
of
the
interaction
and
review
from
key
people.
If
this
is
the
right
direction
to.
G
C
O
C
B
C
U
I
agree:
I
disagree
that
class
this
should
be
limited
to
class
1
devices
in
real
world
exploitation.
Since
the
the
draft
leads
with
vulnerability
patching
as
security
guy,
all
of
the
IOT
botnets
out
there
today
effect
class,
2
or
3
I
two
devices,
nothing
affects
the
class
1.
So
it's
not
really
solving
problem.
Yeah
right.
C
I
agree
so
I'm
co-chairing
the
tip
off
as
well
and
I
think
what
I've
seen
on
the
teeth
Bach
was.
They
would
love
for
it
to
apply
to
other
things.
The
teeth
would
apply
to
you,
which
are
not
necessarily
class
1.
So
I
think
we'll
verify
that
on
Wednesday,
but
my
expectation
is
the
teeth
off
will
be
very
happy
to
hear
that
you
are
not
scoping
it
down
to
only
class
1,
okay,
anything
else
David
or
shall
we
go
on
to
the
jabber
comments?
No,
that
is
it.
Okay.
Thank.
S
S
M
So
my
take
on
this
is,
if
some
chance,
one
devices,
are
obviously
fairly
small
devices,
as
you
mentioned,
and
the
code
that
we
are
talking
about
here
is
code
that
goes
into
the
bootloader.
It
needs
to
swap
out.
J
Paul
Hoffman
because
you
asked
so
there
is
history
in
the
IETF
of
crypto
working
groups
that
produce
more
than
one
format
for
the
same
thing
and
they
failed
misery.
So
just
for
historical
reasons,
I
would
say
picking
one
you
know
it
has
always
has
always
worked
better
and
in
the
one
and
I'm
sorry
I,
don't
remember
the
name
of
the
working
group
that
did
that
it
did
a
asn.1
and
adjacent
output.
It
just
everyone
agreed.
It
was
a
terrible
mistake
afterwards.
S
Okay,
so
before
we
move
on
are
the
rest
of
the
queue
we
do
have
another
jabber
comment
that
came
in
earlier
so
get
that
and
now
this
is
also
from
assuage
Nanda
Kumar.
This
is
would
like
to
add
text
on
architecture
for
how
to
find
the
server
to
get
the
firmware
and
how
to
download
it.
I
think
that's
more
of
a
comment
than
a
question.
V
The
device
can
do
one
butBut,
but
the
server
that
provides
the
manifest
can
support
multiple
formats
if
the
device
does
not
do
yes
and
not
one,
but
it
does
seem
or
you
should
be
able
to
get
that
for
version
of
the
manifest
from
the
server,
because
server
supports
multiple.
So
my
question
was
more
on.
Why
are
restricting
the
encoding
format
to
be
one
format
that
was
on
the
encoding?
V
And
the
second
question
was
more
on
the
transport
mechanisms
like
how
do
we
get
the
firmware
to
the
device
and
I
think
the
Charter
should
talk
about
like,
like
the
earlier
discussion
that
cousin
had
about
the
transport
mechanism
that
using
the
existing
transport
mechanism
mechanism?
How
do
we
find
where'd
we
get
the
firmware
from
and
how
do
we
download
it?
At
least
the
Charter
should
have
some
some
text
on
that,
and
how
do
we
solve
that
in
this
working
group?
Thanks.
T
Yet
yet
told
a
second,
so
I
find
the
charter
to
be
fairly
imprecise,
or
you
know
helpful,
to
figure
out
which
type
of
features
in
the
architecture
would
be
in
and
out
of
scope.
It
just
refers
to
this
wonderful
workshop.
Without
you
know
pointing
to
a
particular
you
know
set
of
output.
That
would
be
you
know,
a
guideline,
the
initial
text
that
basically
says.
Okay,
we
want
to
do
a
solid
firmware
upgrade
scheme,
and
here
are
the
component.
It
consists
of
I
would
kind
of
contest
that
those
components
are
not
sufficient
right.
T
So,
for
example,
one
of
these
things
that
I
think
is
totally
necessary
for
a
solid
upgrade
is
an
automatic
downgrade.
Unless
you
know
some
external
verification
has
happened,
that
the
new
firmware
is
running
or
methods
to
query
what
bloody
keying
material
you
need
on
a
firmware
that
will
be
accepted
by
the
device,
because
it's
not
on,
let's
say
the
standard
vendor.
You
know
key
material
requirements
anymore,
but
I.
You
know
keying
requirements
downloaded
by
the
owner,
so
I'm
questioning
the
original
framework
as
being
sufficient
and
I.
T
B
On
some
of
the
conversation
we've
had
so
far,
its
capabilities
and
IOT
devices
are
not
ubiquitous
and,
in
that
regard,
to
some
some
may
have
the
ability
to
do
a
downgrade
as
you've
suggested
and
others.
Others
may
not.
That
that's
one
reason
why
we
haven't
constrained
the
scope
of
the
work.
You
know
to
two
devices
with
specific
kinds
of
functionality.
R
Martin,
some
on
Thomson
I,
wanted
I
want
to
sort
of
ask
about
the
the
process
we're
following
here,
because
it
seemed
like
we
got
a
bunch
of
questions
about
the
the
rest
of
the
text.
Paul
made
a
comment
about
4108
and
we
haven't
done
anything
about
addressing
that.
We
also
had
a
response
to
to
Fluffy's
question
about
the
transport
and
the
conclusion.
R
There
is
not
very
well
supported
in
the
Charter
as
it
stands
right
now,
the
it
says
will
not
define
any
transport
mechanisms
could
be
read
to
imply
the
conclusion
that
Cullen,
which
received
from
that,
which
was
to
say
that
we're
not
going
to
touch
any
transport
mechanisms
at
all.
Where
my
reading
of
response
to
the
question
was
that
we
will
perhaps
select
one
or
some
subset
of
the
existing
transport
mechanisms
and
use
those
in
some
fashion,
and
so
that
needs
to
be
clarified.
Someone
so
I
do.
C
Know
the
process
that
I'm
using
for
editing
is,
if
they're,
still
big
mic
line,
then
I'm
waiting
to
hear
what
other
people
say
to
see
whether
that
was
one
person
or
whether
there
seems
to
be
you
know,
consensus
or
strong
disagreement
and
so
I
put
in
a
question
mark
in
those
two
places
to
say.
Oh,
those
are
kind
of
pending
open
questions
to
see.
I
can't
tell
until
we
drain
the
mic
line.
Okay,.
C
W
W
H
H
H
H
H
The
the
topic
I
was
trying
to
get
as
this
class
one
device
I
don't
understand
what
it
means
for
the
Charter
I
think
we'd
have
to
be
clear
about
what
percentage
of
the
device
through
the
bootloader
used.
If
we're
going
to
say
it
needs
to
work
on
trying
to
sacrifice
the
price
I,
never
talk
about
the
size
of
the
bootloader,
then
then
a
clock,
one
device
for
the
specific
restrictions
and
the
example
I
give.
If
you
can't
differentiate
between
using
pot,
you
know
whether
to
eat
loader
is
5%
the
device
representing
option.
H
C
H
Popular
like
it,
and
we
certainly
don't
understand
what
was
clicked
into
a
class
one
devices.
You
need
the
charger
to
say,
and
you
can
boot
order
to
run
on
devices.
Bootloader
could
have
these
types
of
resorts
and
knows
not
my
class,
what
not,
since
the
IOT
but
instead
say
whatever
we
think
that
means
or
not
about
the
system.
Do
you
care
what
number
or
how
much
RAM
it
needs
to
be
I
think
we
just
need
to
be
specific
about
it
and
we're
what
we
have
right
network
using
so.
C
I
C
C
Would
say
it
I,
don't
think
the
Charter
says
one
way
together,
I
think
it.
It
would
be
in
scope
if
it's
necessary
to
do
one
of
the
items
that
is
mentioned
so
the
architecture
and
the
manifest
format
are
currently
proposed
as
being
in
scope
and
so
I
say
identifier.
Discussions
would
be
part
of
those,
it
would
be
a
separate
item
in
itself.
I
see
like
no
chair
nodding,
so
I
think
that's
the
current
intent
anyway.
I
would.
I
C
I
think
we're
saying
is
I.
Don't
think
we
hear
the
argument
why
it
needs
to
bubble
up
into
the
dirt
or
text
yet,
as
opposed
to
just
be
in
the
document
for
architecture
and
the
dock
for
manifest
or
documents
or
whatever
I.
Think
that's
what
we're
asking
yeah
is
there
a
reason
that
needs
to
show
up
in
the
Charter
text,
because
it
is
the
scoping
question?
Is
it
big
enough
or
whatever
great,
because
we're
not
getting
why
it's
big
enough
to
appear
in
the
Charter
check
and.
I
C
Missed
a
word
out
of
there
are
multiple
transports,
and
so
we
said
before
that
at
least
what
we're
hearing
on
the
list-
and
here
is
that
discussion
of
how
to
use
existing
transports
parentheses
like
how
you
might
use
collab
or
ACP
or
something
under
the
covers,
as
in
scope
defining
it
means
that
discussion
about,
should
you
be
capable
of
using
HD
should
be
capable.
You
didn't
collapse,
you'd
be
capable
using
something
else
perfectly
in
scope.
The
architecture
the
Charter
text
does
not
have
to
preclude
that.
C
R
M
You
have
comment
on
a
couple
of
points.
One
was
on
on
the
Arias
question
of
it
needs
to
allow
updates
of
devices
other
than
their
manufacturer,
and
I
think
the
problem
is
that
the
manufacturer
is
a
little
bit
used
in
a
very
generic
fashion
because
they
actually
four
devices
they're
many
manufacturers
in
in
that
picture,
is
you
have
the
chip
manufacturer,
maybe
multiple
of
them,
because
you
have
multiple
chips
and
different
components.
Oh
these
are
all
manufacturers.
You
have
guys
that
put
your
board
together,
your
PCP
manufacturer.
M
You
have
the
company
that
actually
develops
the
product
with
maybe
an
OEM
that
provides
the
device
and
so
on,
and
so
on.
So
who
exactly
is
allowed
to
update?
What
are
is
a
policy
decision
and
I?
Don't
think
we?
We
can
cast
this
into
a
specification
as
such
that
there
will
be
that
there
is
a
decision
on
what
firmware
the
device
accepts.
M
M
You
the
other
point
that
Cullen
raised.
He
talked
about
the
bootloader
and,
of
course,
they're
different
designs
on
on
boot
loaders
and
if
you
look
at
the
slide
deck
that
that
was
updated
uploaded
from
from
my
presentation
in
the
appendix
it
has
a
couple
of
design
decisions
on
how
people
are
designed.
Boot,
loaders
and
the
bootloader
in
general
is
part
of
the
whole
sort
of
class
one
class
through
these
categories
and
these
classes
shouldn't
be
taken
to,
in
my
opinion,
shouldn't
be
taking
to
literally
like
in
terms
of
the
kilobytes.
M
But
it's
just
a
rough
indication
that
we
are
that
there
is
a
difference
between
some
low-end
microcontroller
versus
your
high-end
server
or
or
your
laptop
that
you
have,
if
you
are
smartphone
they're,
just
different
capabilities
and
if
we
managed
to
design
something
that
works
specifically
well
for
your
Linux
based
device
that
has
some
software
distribution
platform
like
docker.
That's
a
very
different
software,
a
big
update
mechanism
with
very
different
requirements
with
very
different
players.
D
I
think
on
the
on
the
network,
discoverability
side
and
on
the
transport
side,
the
IT
folks
that
are
sitting
in
front
those
devices
and
are
trying
to
manage
updates
going
to
those
devices
do
very
much
care
what
this
group
has
to
say:
I
think
on
the
device
side,
we're
probably
better
off
with
a
simple
BCP,
describing
things
like
how
you
do
signing
and
encryption
or
that
they
should
be
there
at
a
minimum.
The
rest
of
this
just
seems
like
us,
spinning
our
wheels
I
think.
C
J
Yep
so
Paul
Hoffman,
so
a
a
very
short
proposed
update,
is
to
the
group
will
not
define
any
new
transport
mechanisms.
I
think
that
that
would
have
cleared
up
most
of
the
transport
questions
and
then
actually
I'm.
The
person
for
me
just
had
said
about
discovery.
I
think
discovery
is
extremely
important
and
I
think
there
are
plenty
of
discovery,
things
and
you
so
it
could
also
be.
The
group
will
not
find
any
new
discovery
mechanisms,
but,
but
that
makes
it
clear
they
might
be
in
scope.
J
X
Petrescu
I
would
like
to
add
a
question
mark
on
the
class
one
terminology,
because
I
work
with
a
particular
manufacturer
of
device
that,
when
I
when
he
says
class,
1
class,
2
class
3,
it's
a
laser
class
device
and
it's
not
a
IOT
class
device.
Okay,
so
I
strongly
questioned
this
terminology
of
class
1
class,
2,
plus
3.
X
X
C
X
Second
comment:
I
have
is
that
I
want
to
echo,
maybe
a
third
or
a
fourth
time
what
was
said
in
the
queue
that
we
don't
know.
What
is
an
IOT?
It's
not
that
it's
just
a
small
device.
Okay,
I
work,
a
lot
with
IOT
and
I,
see
I
I
saw
those
know
them
arm
PCB
mojo
from
small
device
up
to
big
platforms
like
IBM
IOT
platform.
Okay,
it's
a
big
server
is
a
data
center.
Okay,.
G
X
X
M
Not
defined
IOT,
but
the
point
I
want
to
actually
talk
about.
What's
Shawn's
comments
on.
M
Trying
to
refer
to
chance
comment
earlier
that
the
IOT
manufacturers
don't
care
about
what
this
group
says.
This
group
doesn't
yet
exist,
so
it's
obviously
difficult
for
them
to
care
about
it
in
there
are
some
so
far
on
the
mailing
list.
We
had
a
couple
of
people
who
produce
operating
systems,
IOT
operating
systems
and
they
seem
to
care
enough
to
participate
and-
and
we
had
David
speaking
earlier,
he
works
on
MCU
but--.
M
We
had
Mia
Manuel,
he
works
on
the
riot
OS,
we
were,
we
have
our
operating
system,
M
addressed,
Huawei
has
an
operating
system,
and
if
we
manage
to
reach
out
after
we
created
such
a
group
to
reach
out
to
more
ayat
the
operating
system
vendors,
then
hopefully
they
will
care.
But
of
course,
it's
hard
to
say
up
front
before
we
have
actually
started
whether
anyone
about
the
outcome
of
the
would.
C
Run
through
and
see
if
I
have
correctly
captured
the
feedback
in
the
room
on
their
charter
text,
and
we
won't
necessarily
do
the
word
smithing
right
now,
but
I
want
to
see
if
we
have
captured
the
intent
correctly
and
then,
as
you
know,
chairs,
maybe
we
can
go
off
and
do
the
words
nothing
to
try
to
match
the.
So
let.
C
Down
the
question
marks,
the
first
comment
was
we
want
to
reduce
the
text
about
4108
I
heard
people
saying
that
it
should
either
not
mention
or
mention
only
and
passing
at
best,
as
opposed
to
concentrate
on
4108
I'd,
not
hear
anybody
arguing
to
keep
4108
text
and
so
I
think
the
intent
is
to
remove
as
much
as
possible
the
scoping
of
text
around
what
we
will
do
with
respect
to
4108.
Okay,
I
think
I've
captured
that
correctly.
C
If
you
disagree
that
you
think
that
we
need
to
keep
text
pacifically
about
41
away,
come
now,
I
heard
very
tiny
homes,
and
so,
if
you
think
that
we
should
remove
all
text
of
4108,
please
hum
okay,
and
that
was
not
a
binary
question
because
in
between
there
is
leaving
some
text
and
passing
right,
and
so,
if
you
think
it
is
useful
to
leave
4108
text
in
passing,
but
not
say
that
we'll
do
an
update
to
it.
Let's
don't
mention
it.
Please
help.
C
Okay,
so
I
think
I
heard
slightly
louder.
Hums
in
the
second
well,
pretty
close
between
second
and
third
is
about
the
relationship
to
class.
One
devices
and
I
think
I
heard
people
saying
that
it
should
not
be
constrained
to
class
one
devices
and
the
text
should
be
updated
to
make
that
clearer.
That
is
not
updated.
C
That
any
solution
coming
out
of
here
would
be
capable
of
applying
to
a
class
one
device.
It
is
not
solely
for
class
one
devices,
but
it
shouldn't
have
a
dependency
that
would
not
fit
on
a
class
one
device.
That
is
the
intent.
Okay
I
see
is
not
the
next
one
is
about
what
is
out
of
scope,
and
so
we
talked
about
not
defying
any
new
transport
protocols.
I
think
we
wrench
in
this
a
couple
times
that
use
of
transport
protocols.
Discussion
is
in
scope.
C
When
we
talk
about
architecture,
defining
new
ones
is
not,
and
the
related
point
that
is
both
up
here
and
down
here
so
I'll.
Ask
it
now
is
the
notion
of
how
do
I
discover
the
place
that
I
get
stuff
from
should
be
in
scope?
I
heard
people
arguing
for
that
I
think
even
the
manifest
format
proposal
includes
some
discussion
of
that.
Inserting
the
architecture
would
and
so
I
think
the
intent
is
that
this
discussion
of
discovery
is
in
scope,
but,
as
Paul
I
think
was
Paul
that
mentioned
new
discovery.
Protocols
are
out
of
scope.
C
T
G
B
C
Mentioning
it
in
the
Charter,
as
opposed
to
leaving
to
the
documents,
the
notion
of
the
architecture
or
some
other
way
of,
can
help
us
things.
I
put
it
as
a
place
within
the
architecture,
a
way
of
a
description
of
the
capabilities
of
a
device
or
some
notion
that
says
how
do
I,
discover
and
negotiate
the
capabilities
of
the
device
we'll
have
to
figure
out
what
the
right
wording
is.
C
But
the
question
is
to
the
charter:
have
text
about
the
capabilities
of
the
device
being
sort
of
key
to
the
to
what
this,
what
the
group
will
do.
So,
if
you
believe
that
we
need
text
to
talk
about
capability,
negotiation
or
discovery
or
whatever,
the
right
term
is
something
in
that
category.
If
you
think
we
need
text
to
address,
because
right
now,
there's
no
text
dimension
says
right.
If
you
think
the
Charter
text
I'm.
T
C
Here
is
whether
you
think
we
need
charter
text
or
whether
the
Charter
is
okay
in
the
absence
of
list
and
leave
it
to
the
document.
Okay,
that's
the
actual
question.
Okay.
So
if
you
think
that
the
charter
needs
text
about
this,
please
hop
if
you
okay,
if
you
think
it
is
sufficient
to
leave
it
out
of
the
Charter
but
into
the
architecture
document
discussion,
please
help.
C
Servers
here
we
go.
Maybe
the
last
one
during
this
discussion
is
the
notion
of
should
the
Charter
constrain
us
for
having
one
manifest,
including
format,
or
should
the
Charter
not
mention
any
constraint
if
the
charge
doesn't
mention
the
constraint,
that
means
it's
up
with
a
working
group
to
make
that
decision
post
charter-
that's
in
the
Charter,
it
means
we're
who
did
from
having
that
discussion.
C
So
if
you
believe
that
charter
should
constrain
us
to
doing
one,
please
hum
if
you
believe
the
Charter
should
not
have
a
constraint
and
should
not
mention
this,
and
it's
just
part
of
the
working
groups
work
to
decide
that
please
hum
okay,
I
heard
a
strong
home
for
not
mentioning
the
word.
One
here
record
that
and
I'm
hoping
the
note-taker
will
also
record
that,
to
the
figure
will
figure
out
some
wording
that
does
not
constrain
us.
Okay,
that
is
the
end
of
my
question.
Mark
things.
B
B
C
It
I
think
you're,
right,
I.
Think
I
actually
didn't
ask
that
as
a
question
I
should
so.
Thank
you
so
I
think
the
question
is,
if
you
feel
that
the
Charter,
as
opposed
to
the
documents,
if
you
get
charter,
should
mention
that
we
will
do
work
on
discovery
of
update
servers,
I
think
that
was
how
the
original
comment
was
phrased.
If
you
think
we
need
to
have
some
charter
text
about
that,
okay-
and
there
might
be
multiple
reasons
to
say-
yes,
multiple
reasons
to
say
no,
the
question
is:
should
we
need
to
do?
C
C
Z
This
is
Hank
I'm
I'm
at
least
a
little
bit
confused
to
be
that
covered.
The
first
discovery
question
actually
I
think
we
yeah.
C
C
C
C
T
No
no,
but
the
point
is
that
anybody
can
reject
anything
about
capabilities
and
and
discovery
in
anything
by
pointing
to
this
first
block.
A
firmware
update
solution
consists
of
right,
so
I
think
that
is
too
constraining
that
text
a
firmware,
update
solution
consists
of
well,
okay,
says
several
components,
including,
but
I
mean
that
that's
that's.
Where
things
like
discovery
or
capability,
you
know
discovery
of
service
capability
of
devices.
That
would
be
additional
communication.
S
S
C
C
I
sense
the
room
before
was
that
no,
but
if
you
think
the
answer
was
no,
that
the
tent
that
the
Charter
text
does
not
need
this
to
be
mentioned
exclusively.
It's
okay
to
move
the
architecture
document,
please
home
a
bunch
of
people
either
didn't
care,
didn't
understand
the
question
say
it
slower:
okay,
Colin
proposes
the
following
sentence:
the
architecture
should
provide
a
way
to
discover
the
update
server
or
some
wordsmith
variation
thereof.
Do
you.
C
C
M
D
C
Okay,
I
people
believe
that
the
architect
that
my
recollection
here
maybe
note-taker,
helped
me
verify
my
co-chair-
is
that
discovery
mechanisms
are
in
scope
for
the
architecture,
but
we
didn't
necessarily
need
specific
text
in
the
Charter
to
say
that
that's
correct,
okay,
I
have
two
yeses,
that's
okay,
great,
so
they've
wanted
to
then
go
to
our
last
legs,
we're
almost
out
of
time
and
so
I
might
in
affected
Dave
here,
wrap
up.
That's
a
yes!
Yes,.
B
So
so
we're
going
to
gather
immediately
after
this
and
and
and
start
working
on,
addressing
all
of
these
changes
to
the
Charter,
probably
within
the
next.
You
know
next
few
days
we'll
have
hopefully
real
soon
we'll
have
an
update,
updated
charter
I
back
on
the
list,
so
that
we
can
continue
the
the
Charter
conversation.
B
So
I
want
to
have
a
brief
discussion
about
how
we
might
move
forward
with
this
effort
if,
if
it's
chartered
so
if
it's
Charter
will
obviously
meet
at
ATF
101,
but
is
there
interest
in
the
room
and
we
weren't
able
to
actually
have
much
conversation
today
about
potential
solutions
and
architectural
concerns?
Is
there?
Is
there
interest
in
the
room
and
having
a
virtual
to
start
to
discuss
that
I'm?
Seeing
some
nods
can
I
get
a
show
of
hands
if
who
might
attend.
C
B
B
You
so
so
with
that
I
think
we
can.
We
can
conclude
this
bomb,
so
thank
you
all
for
coming.