►
From YouTube: IETF-MIMI-20230928-1900
Description
MIMI interim meeting session
2023/09/28 1900
https://datatracker.ietf.org/group/mimi/meetings/
B
A
C
C
B
A
B
A
Yep
sounds
good:
okay,
we're
going
to
go
ahead
and
kick
off.
Welcome
back
to
Mimi,
here's
the
not
well
it
governs
our
meeting
today
and
references
all
of
the
itf's
policies,
including
IPR
code
of
conduct
and
other
things.
So
please
take
a
look
if
you're
not
familiar
and
stick
with
the
policies
as
I
previewed
I
would
be
asking
for
a
note
taker.
Would
anybody
be
willing
to
take
notes.
A
Thank
you,
so
here's
our
agenda
for
today
it's
it's
design
team
day,
so
we
will
turn
it
over
to
Richard,
Conrad
and
Travis
to
present
the
five
draft
five
draft.
Yes,
that
have
come
out
of
the
design
team's
work.
They
have
kind
of
60
Minutes
of
presentation
prepared
and
then
we'll
have
lots
of
time
for
discussion
as
well.
So
that's
the
plan
for
today.
Does
anybody
want
to
bash
the.
A
A
B
A
B
C
C
G
G
C
C
C
G
C
C
All
right
so
cool,
so
this
is
going
to
be
an
update
from
the
design
team
on
kind
of
the
documents
we
sent
around
and
some
further
discussion
that
happened
among
the
design
team
after
we
got
those
out,
so
I
would
consider
as
as
we're
going
through
this
consider
the
the
documents
kind
of
a
snapshot
of
where
we
were
like
a
week
and
a
half
ago,
and
we've
had
some
substantive
discussion
after
that.
That's
reflected
in
the
slides
and
in
the
discussion
portion
after
we
can.
C
We
can
discuss
you,
know
kind
of
where
to
go
in
terms
of
revving
the
documents
or
adoption,
or
what
have
you
so
next
slide?
If
you
could
scroll
down
please
Tim.
The
plan
for
this
first
chunk
of
time
is
to
kind
of
walk
through
where
we've
gotten
from
a
design
point
of
view,
we'll
start
from
the
top,
as
usual,
reviewing
architectural,
Concepts
and
kind
of
map.
C
How
the
current
documents
reflect
that
that
architecture
and
I
I'll
walk
through
those
two
two
bullet
points
and
then
Travis
and
Conrad
I'll
pass
over
to.
They
have
worked
through
kind
of
how
some
example
scenar
some
you
very
basic
example.
Scenarios
work
in
this
framework
we're
we're
arriving
at
with
the
idea
that
you
could.
The
documents
as
they
exist
are
pretty
close
to
being
a
able
to
implement
these
scenarios.
C
So
the
idea
is
to
kind
of
give
folks
an
idea
of
how
the
various
bits
in
the
documents
fits
together
to
actually
do
messaging
stuff.
So
that's
the
plan
and
then
at
at
the
end,
we've
got
a
bunch
of
time
for
discussion
discussion
both
you
know
substantive,
and
you
know
what
people
think
about
the
actual
architecture
here
and
and
procedurally
what
we
should
do
about
documents
and
adoption.
So
with
that
I
think
we
can
dive.
D
C
C
Please
this
picture
should
be
familiar
right
now,
it's
unmodified
since,
since
the
ITF
meeting
this
is
our
classic
client
server
to
server
to
server
to
client
architecture.
Where
you
know
the
Mimi
scope.
Is
this
room
that
spans
several
servers
and
then
things
between
clients
and
servers
are
are
within
the
provider
domain?
Next.
C
Slide
this
is
also
I,
think
unchanged
since
last
time.
So
just
to
remind
folks
that
you
we
have
this
concept
that
each
room
is
hosted
on
a
hub
server
for
now
we're
assuming
that
Hub
server
is
constant
over
time
that
the
room
always
lives
in
a
single
place.
There
is
a
of
Hub
portability
that
that
has
been
discussed,
but
I
think
we're
we're
puning,
that
for
now
and
assuming
the
Hub
is
constant
for
the
moment.
C
C
C
Before
the
unit
of
functionality
we
have
here
is
a
room,
a
room.
In
addition,
you
know
room
has
messages
that
go
by.
Of
course,
I
didn't
just
kind
of
left
implicit
here,
the
remainder
of
the
information
of
the
room
about
a
room.
We
call
the
state.
So
that's
all
the
stuff
that
doesn't.
This
relates
to
the
you
know
the
what
a
room
is
how
it
works
is
not
all
all
the
messaging
stuff
happening
inside
the
room,
and
so
there's
a
few.
You
components
that
we
have.
C
You
know
in
mind
right
now,
for
that
state,
an
authorization
policy
that
says
things
like
what
users
can
do,
how
people
can
join
a
list
of
users
who
are
participants
in
the
room.
The
participant
list
will
use
that
phrase
going
out
forward
and
an
MLs
group
attached
to
that
group.
So
some
end
to
encryption
State,
including
part
of
that
state,
a
list
of
the
clients,
the
specific
devices
who
are
members
of
that
group,
so
we',
we've
established
kind
of
parallel
terminology,
so
the
word
member
is
is
relates
to
client.
C
C
You
know
the
MLS
group
will
have
a
list
of
members
and
the
room
will
have
a
list
of
participants
and
we'll
talk
a
in
a
little
bit
more
detail
about
those
in
just
a
second
once
you
have
this
distinction
between
users
and
clients.
There's
a
question
of
you
know
whether
a
user
this
this
distinction
allows
for
users
who
have
no
clients
join
to
the
room
who
clients
who
are
not
members
of
the
MLS
group.
C
Sorry,
a
user
who
is
a
participant
in
the
room
may
have
no
clients
that
are
members
of
the
corresponding
MLS
group.
So
that
means
we
need
to
distinguish
two
types
of
users:
users
who
are
who
do
have
MLS
clients
in
in
the
group
or
users
who
don't
and
the
terminology
we've
landed
on.
There
is
active
or
inactive,
so
a
participant
in
the
room
that
has
clients
joined
is
active
because
they
can
do
everything
they're
part
they
have
all
the
all
the
state
they
need
to
participate
in
the
room
in
in
arbitrary
ways.
C
C
I
C
C
Group
well
at
the
moment,
in
the
epoch
that
commit
initiates.
Your
client
is
a
member
of
the
MLS
group.
So
as
when
that
commit
is
accepted
by
the
you
by
the
room
by
the
clients
in
the
in
the
in
the
in
the
room,
then
your
client
will
be
part
of
the
MLS
group
and
you
will
be
an
active
user,
so
yeah
a
user
can
be
activated
without
any
action
on
their
own.
Besides,
providing
that
key.
C
Yeah
I
mean
that
that
touches
on
the
the
question
of
consent
you
know
under
under
what
circumstances
can
Eric
be
added
to
a
room
or
Eric's
clients
be
added
to
a
room
which
I
think
we
we
have
not
dived
into
a
whole
lot,
in
particular
fun
in
the
in
the
examples
we've
got
here
today,
but
it's
a
it's
a
question.
It's
a
good
question
we'll
need
to
to
work
out
the
nuances
of
that
as
we
go
last
thing.
C
I
want
to
touch
on
in
this
slide
is
that
in
earlier
discussions
we
talked
about
something
called
a
policy
envelope
that
I
think
is
a
little
ambiguous
in
in
I.
Think
we
need
some
more
refinement
around
that
we
need
to
you.
The
policy
envelope,
I
think
with
the
idea
when
we
talked
about
it
before
was
a
thing
that
the
Hub
would
specify
that
were
the
immutable
parts
of
the
or
the
the
bounds
on
these
set
of
acceptable
authorization
policies
for
a
room.
C
C
Please
I
thought
it
would
be
useful
to
visualize
this
actually
I'm
borrowing
from
some
some
visualization
that
Travis
put
together
and
Conrad
right.
So
this
is
just
visualizing.
The
state
of
the
room,
starting
from
the
right
is
the
most
concrete
thing
you
know
the
MLS
group
is
the
set
of
clients
that
have
have
the
keys
for
the
end
encryption
of
the
room.
There's
an
assumption.
C
I
think
we've
been
making
along
that
I
meant
to
document
these
slides
that
I
forgot
to
that
each
client
in
based
on
their
representation
in
the
MLS
group.
From
from
that
representation,
it
is
possible
to
infer
which
user
a
client
belongs
to,
and
so
that
there's
actually
a
mapping
between
these
clients,
which
I've
implied
with
the
numbers
but
meant
to
put
lines,
should
have
Drawn
Lines
to
so
that
there's
a
mapping
between
those
clients
in
the
MLS
group
and
the
and
the
participants
in
the
participant
list.
C
As
you
can
see
in
the
participant
lists
user,
one
we've
got
three
users
who
are
are
are
possibly
participating
or
participants
that
have
a
relationship
with
the
room
user,
one
and
user
two
have
clients,
joined
and
so
they're
active
user
three
doesn't,
and
so
they
are
inactive.
But
all
three
of
those
are
you
because
they're
in
the
participant
list,
they
can
be
subject
to
you,
they're
part
of
the
room,
and
so
they
can
be
part
of
the
the
policy
structure
of
the
room.
C
The
room
can
have
a
notion
of
what
capabilities
each
user
has,
and
so
they
can
say
that
user
one
is,
is
an
admin
or
user.
Two
is
a
moderator
Etc,
and
the
policy
document
also
CT
captures
things
like
the
admission
policy,
how
it's
possible
to
join
and
other
kind
of
authorization.
Things
like
that.
So
we
split
out
this
this
structure,
because
what
we're
actually
going
to
build
protocols
kind
of
in
parallel
to
manage
the
different
bits
of
this
next.
B
C
Please
so
one
of
the
consequences,
though,
of
splitting
out
the
room
State
like
this
and
building
independent
protocols
to
manage
the
different
bits
of
State.
You
know
the
benefit
of
having
separate
protocols
is
that
each
protocol
can
do
what
it's
good
at.
So
MLS
is
good
at
managing
a
cryptographic.
You
know
some
group
cryptographic
State,
not
so
good
at
managing
authorization
policy,
so
we
have
separate.
You
know
horses
for
courses
for
the
different
bits
of
State.
C
The
downside
of
having
separate
management
of
these
things
is
that
those
things
can
get
disconnected
that
you
could
have
INF
princi
principle,
a
participant
list
that
was
inconsistent
with
the
MLS
group.
So,
in
addition
to
doing
splitting
things
out
and
managing
things
being
able
to
manage
each
thing
independently,
we
need
to
Define
what
how
these
things
interlock
with
each
other
a
little
bit-
and
this
was
a
point
of
of
some
discussion
in
the
group
but
I-
think
we'.
We've
aligned
pretty
well
on
this.
C
C
One
of
the
things
you'd
like
to
assure
about
this
room
state
is
that
everyone
involved
in
the
room
has
the
same
view
of
the
state.
So
all
the
clients
and
all
the
servers
have
the
same
view
of
the
room
state.
Now,
that's
you
know.
As
with
anything
that
can
change
it's,
there
might
be
some
some
time
lag
in
in
this
confirmation,
but
the
goal
is
to
keep
this.
You
know
to
confirm
that
we
all
agree
with
some
Fidelity
to
you,
some
proximity
to
the
changes
that
happen
in
in
the
group.
C
So
the
the
way
you
know
the
mechanism
proposed
here
is
to
to
use
the
MLS
key
schedule
as
a
confirmation
mechanism.
So,
in
case
folks
are
familiar
need
a
reminder
if
you
inject
a
value
into
the
MLS
key
schedule,
that
value
gets
hashed
into
the
state
of
the
MLS
group
and
thus
into
the
all
of
the
keys
that
the
the
clients
use,
which
means,
if
you,
if
you
disagree
on
this
value,
that
you
hashed
into
the
key
schedule,
then
you
can't
communicate
your
keys,
will
all
be
different.
C
So
the
the
concept
for
confirmation
here
is
to
take
the
whole
room
State,
including
the
you,
the
MLS
State,
already
goes
in
by
virtue
of
MLS,
but
to
also
take
the
authorization
policy
in
the
participant
list
and
hash
those
into
the
MLS
key
schedule,
so
that
you
know,
in
order
for
the
group
to
continue
functioning.
Everyone
has
to
this
have
the
same
view
now
functionally
how
how
I
think
we
expect
this
to
work.
C
Is
that
you
we
have
some
group
context
extension
using
some
existing
stuff
in
MLS
extensibility
points
and
then
each
commit
that
is
made
to
update
the
MLS
group
to
reflect
new
changes
to
the
room
State.
You
know
if
a
user
joins
and
we
want
to
add
some
clients
for
them.
Each
commit
you
know
will
be
enforced
by
The
Hub
to
reflect
the
current
room
state
so
that
will'll
have
to
carry
one
of
these
extensions
that
updates
the
the
MLS
confirm
state
to
match
the
current
room
State.
C
The
way
I've
drawn
the
blue
arrows
here
is
perhaps
a
little
confusing.
What
I
mean
there
is
that
you
know
the
MLS
group
will
have
some
extension.
That
you
know
is
a
hash
of
the
rest
of
the
room
State,
and
so
that
will
confirm-
or
you
know,
vet
via
MLS,
the
participant
list
and
authorization
policy,
so
the
MLS
state,
if
you
agree
on
the
MLS
state,
that
means
you
agree
on
the
participant
list
and
you
agree
on
the
authorization
policy.
H
C
H
Yeah,
oh
sorry,
yeah
I'm
justos
want
to
make
sure
I
understand
this
slide,
so
these
arrows
really
meet
so
the
arrows
on
the
top
mean
information
flows,
the
red
arrows
mean
information
flows
downward
and
the
arrows
in
the
bottom
mean
look
over
here
because
I'm
incorporating
that
data
into
myself
right.
So
actually
the
information
is
always
flowing
downward.
C
Right,
yeah,
I
think
think:
that's
that's
a
fun
way
to
think
about
it.
Yeah,
okay,
great
you
well
I
mean
it's
a
little
bit
circular
in
the
in
the
sense
that
the
authorization
policy
governs
the
participant
list
which
governs
the
MLS
group.
But
then
the
MLS
group
confirms
you
know
this.
This
hash,
that's
in
the
MLS
group
confirms
that
what
the
authorization
policy
participant
was
were
the
last
time
we
made
an
update.
H
C
Please
yeah
so
order
of
operations,
so
these
invariant
on
the
last
couple
slides.
You
know
they're
useful
in
terms
of
clarifying
what
we
mean,
but
they
have
some
implications
for
How
We,
Do
Stuff
in
particular.
If
you
think
about,
joins
and
leaves
things
that
are
going
to
touch
both
the
participant
list
and
the
MLS
group
you
have,
they
have
to
be
done
in
a
particular
order.
C
So
when
I'm,
adding
echer
to
the
room
right,
I,
I'm,
I'm
gonna
want
to
add
eer
as
a
user
and
some
of
ecker's
devices,
and
so,
if
we're
going
to
have
this
preemption
order
in
the
you
know,
as
the
the
kind
of
orange
arrows
indicate,
then
I
need
to
make
sure
that
eer
is
added
to
the
participant
lists
before
I.
Add
his
clients,
because
if
I
try,
if
the
ad,
if
the
MLS
ad
shows
up
first,
that
you
echer
won't
be
in
the
participant
list
and
that
commit
will
get
rejected.
C
So
you
know
we
need
need
to
do
ads
at
the
participant
list,
level
first
and
then
at
the
MOs
level,
and
then,
when
I'm,
removing
echer
from
the
room.
It's
the
reverse.
So
I
need
to
make
sure
all
of
ecker's
clients
are
removed
before
eer
can
be
removed
from
the
participant
list,
because,
if
I
remove
him
from
the
participant
list
before
his
devices
are
gone,
then
he's
actually
not
he's
kind
of
still
a
participant
because
he
can
still
get
access
by
those
devices.
So
the
idea
is
to
have
the
participant
list
reflects.
C
H
H
H
B
C
Yeah
and
I'll
let
row
talking
second
but
I.
Think
that
the
what
I
think
the
design
team
thought
about
that
some
I
think
the
thinking
was
that
it
would
be
clearer
rather
than
proactively,
removing
from
the
participant
list.
While
that
request
was
pending
to
remove
the
devices
to
instead
keep
them
on
the
participant
list,
but
maybe
annotate
it
as
being
in
an
exiting
state
or
something
and.
B
I
The
compromise
that
we
came
to
was
that
there
is,
you
know,
basically,
a
Lego
block
of
stuff
that
manipulates
State
and
the
endend
encryption
and
in
the
case
of
MLS,
the
MLS
chunk
that
you
know
the
the
end
to
end
encryption
has
a
bunch
of
stuff
which
also
manipulate
State,
and
so
the
set
of
things
that
you
need
that
are
outside
of
mLs
are,
you
know,
are
fairly
small
and
possibly
could
be
made
to
be
zero.
If
you
did
this
with
double
ratchet
or
some
other
protocol,
then
the
Lego
block
still
has
the
same.
I
The
the
same
boundaries
and
the
Lego
block
includes
something
that
goes,
and
you
know
basically
does
an
encryption
of
of
sessions
and
things
that
in
in
some
some
other
stuff
that
manages
the
state
of
your.
You
know,
in
this
case
your
mapping
of
the
participant
list
to
specific
sessions.
So
you
can
totally
do
this
with
another
protocol
if
you
want
to,
but
that's
not
in
our
Charter,
but
we
have
made,
you
know
we
have
we.
We
have
been
striving
to
make
sure
that
that
is
that.
That
is
possible
and
you
know,
doesn't
blow
your
head.
H
Well,
yeah.
Maybe
this
is
the
next
slide,
but
I
think
like
there
really
is
a
group
decision
he
made,
which
is.
Do
we
assume
that
the
outer
Contours
of
what
is
required
in
this
Lego
block
are
effective,
what
MLS
provides
and
that
anyone
else
like
has
to
figure
it
out
on
their
own
and
we're
not
going
to
help
basically,
which
is
basically
cied
with
TLS
right?
It's
like
quick
was
basically
designed
to
have
a
hole,
a
TS
shaped
hole
and
it
was
like
your
responsibility.
H
C
Yeah
yeah,
so
can
we
go
to
the
next
slide?
Please,
because
that
is
my
Lego
bricks
slide
for
what
it's
worth.
I
looked
up,
the
I
checked
the
official
terminology
that
Lego
company
I
prefers,
and
it's
bricks,
apparently
is
the
not
blocks.
Is
the
official
name
also
found
the
the
atmology
of
Lego
at
the
bottom,
which
is
about
playing
well,
which
I
thought
was
a
very
appropriate.
C
You
know
you
know
admonishment
for
for
folks
in
the
ITF
to
play
well
together,
but
this
is
kind
of
the
Lego
brick
model
that
that
design
team
has
been
referring
to
in
our
discussions
in
terms
of
what
protocols
need
to
exist
to
make
this
go,
and
this
is
this
is
a
bit
in
the
architecture
document,
but
I
think
this.
This
diagram
probably
needs
to
get
import
into
that
document
in
the
next
draph.
C
C
The
thing
things
that
are
in
the
message
format
are
carried
in
some
inst
end
and
capsulation
and
then
delivered
over
some
forwarding
protocol.
The
interesting
bits
here,
the
parts
that,
if
you've
been
following
the
last
few
slides,
are
these.
These
blue
blocks
for
the
different
protocols
that
manage
the
different
groups
of
State
attached
to
a
room.
So,
like
Rowan
said
we
have
this
end
to
end
thing
which
is
managing
in
you
know:
ietf
Mimi,
MLS,
group
and
I
think
echer.
The
way
echer
framed
is
is
accurate.
C
Is
it
corresponds
to
the
way
the
design
team
has
been
thinking
about
this?
This
is
an
MLs
shaped
hole,
and
if
you
want
to
do
this
with
some
other
protocol,
it's
up
to
you
to
figure
out
how,
to
you
know,
add
whatever
filigrees
you
need
to
to
make
your
thing.
Do
the
things
MLS
does
so
like
confirmation,
that's
that
sort
of
hashing
into
the
key
schedule
doesn't
exist
in
a
lot
of
other
protocols.
So
if
you
wanted
that
security
benefit,
you
might
have
to
do
that.
C
As
an
aside,
I
might
say
that,
like
a
lot
of
things
that
MLS
does,
you
could
do
non-
cryptographically
and
get
lower
security
properties.
So
it
wouldn't
be
surprising
if
folks,
coming
to
this
with
a
different
protocol,
did
things
like
proposals,
but
without
some
of
the
you
know,
confirmation
security
properties
that
that
MLS
gives
you
so
anyway,
we've
got
an
endtoend
block
which
manages
the
cryptographic
state,
the
endtoend
security
Keys.
We
have
a
policy
layer.
C
Sorry
I've
put
these
in
a
different
order
than
the
state
bits
on
the
previous
slid.
That
would
have
been
helpful,
a
policy
bit
that
manages
the
authorization
policy
and
a
signaling
bit
that
manages
the
participant
list.
I've
written
this
gray
block
with
application
logic,
because
that
there's
going
to
need
to
be
something
in
the
software
implementing
this
protocol
that
ties
these
things
together
and
ensures
those
policy.
You
know
those
inter
we
talked
about
on
last
last
slide.
C
A
C
C
If
you
had
an
MLs
stack,
but
you
might
have
to
implement
that
that
data
structure
with
a
different
thing
like
that
that
that
may
be
a
little
bit
of
infection.
But
it's
it's
not
an
inordinate
amount
of
work.
To
add
that
to
your
existing
ctivity,
like
like
I,
was
saying
a
minute
ago
like
no
like
MLS
is
a
little
bit.
You
know,
has
a
bigger
envelope.
C
I
You
know,
basically,
they
need
to
be
sort
of
a
match
pair,
but
the
interfaces
that
you
know
the
interfaces
to
the
application
logic
could
be
the
same
for
for
a
pair,
a
matched
pair
of
MLS,
plus
MLS
related
signaling,
compared
to
a
replacement,
double
ratchet
and
double
ratchet
signal
related
signaling.
So
those
like
that
those
two
pairs
could
have
an
equivalent
lower
interface
and
upper
interface
and
then,
of
course,
message
forwarding,
relies
on
and
dead
encryption,
so
I
I.
You
know
three
three
bricks
is
my
answer:
I
hope
that.
G
Okay,
so
granting
that
we
could
design
some
sort
of
abstraction
over
a
specific
Eed
mechanism
that
would
allow
either
like
MLS
or
something
like
double
ratchet,
to
be
used.
What
does
all
this
mean
for
interoperability
is
the
idea
that
participants
would
have
like
previously
agreed
out
of
band
that
they're
doing
either
double
ratchet
flavored,
Mimi
or
MLS
flavored.
C
B
H
H
Think
it's
entirely
appropriate
to
sort
of
other
part
of
the
document
say
because
this,
because
this
is
carry
MLS,
you
can
do.
We
can
get
away
with
x,
y
and
z,
and
you
know,
and
obviously
as
I
think
I
mentioned
to
you
earlier.
Offline
Richard,
like
you
know
that,
like
MLS,
somehow
like
is
actually
under
under
in
between
message
for
forwarding
your
message.
Format
in
some
unspecified
unclear
way.
So
there
are,
you
know
there
are
tendrils
of
MLS
All
Over.
The
system
I
think
that's
entirely
entirely
appropriate
because.
C
H
E
C
F
Sorry
yeah
the
mute
button
literally
vanished
from
the
Dom,
somehow
so
yeah.
Well,
what
comrad
said
was
what
I
was
going
to
say
about
agility.
Obviously
you
need
version
agility
in
here
anyway,
and
that
can
be
used
to
describe
different
dialects
of
MLS
or
double
ratchet
or
whatever.
It
is
in
terms
of
the
kind
of
transitional
benefits.
A
Language,
so
just
just
Visa
what
everybody
else
in
the
que
just
said.
Do
you
feel
like
what
you
just
said
is
consistent
like
like
people
were
talking
about
there
being,
you
know
some
dependency,
but,
like
you
know,
we
scope
the
size
of
the
whole
and
then
like
people
want
to
use
something
else.
They
use.
Something
else.
Are
you
advocating
for
like
more
decoupling
than
than
what
was
just
discussed.
F
No
I
think
that
the
proposed
decoupling
is
sufficient
from
what
I've
seen
unless
the
gold
posts
are
changing
from.
Since
we
last
spoke
about
the
specifics
on
it
and
I
think
it's
completely
reasonable
that
you
need
a
confirmation
mechanism
and
and
MLS
gives
a
great
confirmation
mechanism.
Other
ones
also
exist
like
the
one
we
proposed
in
linearized
Matrix.
That
can
also
be
used
to
fill
that
hole,
but
I
think
the
strategy
of
saying
look,
it's
an
MLs
shaped
hole.
You
got
to
figure
out
how
to
fill
the
gaps.
F
C
C
So
I
think
the
idea
of
the
next
section
where
Travis
and
con
are
G
to
kind
of
walk
through
some
scenarios
is
to
give
an
idea
of
where
you
know
where
We've
Ended
up
as
a
design
team
on
how
things
should
ought
to
work.
Within
this
framework,
we've
been
discussing
as
as
a
direction
for
where
these
these
documents
should
be
headed.
All.
H
Hway
law
I
spent
some
time
this
morning
going
through
those
drafts
and
why
I
think
there
may
some
reasons
why
they
not
F
were
well,
but
frankly,
it's
incredibly
difficult
to
like
have
like
things
spaced
out
so
much
so
it's
like
this
depends
on
this,
and
this
depends
on
this
and
you
got
to
read
them
and
they're.
All
quas
depended
so
like
what
so
like.
I
do
not
think,
given
that
we
have
no
given
there's
no
intention
of
like
being
able
to
demount
all
these
different
blocks.
B
J
Please
so
yeah
scenario
discussions
is
kind
of
where
we're
at
as
rich
mentioned
in
the
introduction
there.
We
had
two
scenarios
kind
of
laid
out
here,
just
to
kind
of
show
like
what's
going
on
between
the
documents
themselves.
First,
one
here
being
Alice
adds
Bob
second
scenario
will
be
Alice
leaving
that
group.
So
if
we
go
to
the
next
slide,
we
will
start
to
see
some
assumptions
so
yeah.
Here
we
are
assuming
that
Bob's
service,
specific
identifier,
has
already
been
discovered
in
some
way.
J
So
we
are
pass
the
point
of
identity.
We
are
now
strictly
into
protocol
side
of
things
as
well.
We're
assuming
that
any
consent
that
Alice
needs
to
add
Bob
to
the
to
the
room
has
already
happened
or
is
implicitly
given.
There
are
multiple
layers
where
consent
could
be
asked
for
or
achieved,
but
they
are
they're
all
granted
in
this.
This
sort
of
aspect
here
there's
also
many
other
types
of
join
flows,
there's
just
one.
This
is
just
one
example
of
many
here
and.
B
J
We'll
kind
of
head
into
the
next
slide
here
with
all
of
that
as
a
qualifier,
so
the
very
first
step
is
that
Alice
has
to
create
this
actual
group
or
room.
This
happens
outside
of
Mimi.
They
just
create
it
with
their
provider,
but
it
does
have
all
the
initial
State
required
for
Mimi
to
operate.
So
this
is
the
participant
list.
This
is
the
policy.
J
This
is
the
actual
MLS
group
itself
and
all
that
stuff,
but
Alice
does
have
the
optional
ability
to
add
all
of
their
MLS
clients
to
the
group
at
this
point
not
strictly
required
by
the
protocol,
probably
a
good
thing
that
should
happen
but
yeah
it.
It
does
happen.
So
now
we're
going
to
head
into
some
diagrams
here.
If
we
go
to
the
next
slide,.
J
So,
following
that
preemptive
work
or
that
preemptive
U
yeah
workflow,
that
Richard
was
mentioning
signaling
happens
first
for
lack
of
a
better
term,
so
first
Alice
needs
to
create
this
signaling
event
to
actually
invite
Bob
into
the
group
or
into
the
room.
Rather,
all
of
this
invite
stuff,
as
mentioned,
could
just
be
skipped
if
we
use
a
welcome
flow
instead,
that's
another
type
of
way
of
joining,
but
we're
kind
of
we
we're
skipping
that
part
and
we're
covering
specifically
the
invite
and
then
join
as
separate
operations
here.
J
Please
and
then
yeah
well,
Alice
has
to
send
that
invite
to
the
hub
itself
and
that
will
then
be
start
to
get
fanned
out.
So
if
we
go
to
the
next
slide,
we're
going
to
start
seeing
that
the
The
Hub
is
establishing
that
secure
connection
between
what
is
Alice's
server,
because
Alice
is
the
the
Hub
in
this
scenario
and
Bob's
server.
J
And
then,
if
we
go
to
the
next
Slide,
the
fan
out
actually
starts
to
happen,
so
that
invite
event
is
now
being
received
by
Bob
and
on
the
next
slide
we
will
see
that
actual
invite
being
checked
again.
We're
assuming
the
happy
path
here.
So
this
is
where
you
would
check
for
policy.
Support,
does
Bob
server
even
support.
The
type
of
room
that
is
being
discussed
here
is
the
is
the
policy.
Okay
is
the
encryption
supported?
Is
there
consent?
All
of
that
stuff
happens
here?
J
We
assume
that
everything
is
okay
and
move
move
on
to
the
next
slide,
where
we
then
have
again
another
implementation,
specific
detail
here,
where
or
outside
of
Mimi,
where
Bob
server
stores
that
invite
and
eventually
gets
it
over
to
Bob
through
whatever
vendor
specific
API
and
that
sort
of
stuff.
And
then,
if
we
head
to
the
next
slide,
some
amount
of
time
will
have
passed.
J
Bob
will
accept
that
invite
and
we'll
start
to
create
this
join
State
or
the
signaling
State
change,
so
we're
still
well
within
signaling
here,
MLS
or
the
MLS
group
only
has
Alice's
clients
in
it.
Bob
is
still
in
the
invite
State
here
on
the
next
slide
that
join
will
head
back
up
that
secure
channel
from
the
transport
into
the
Hub
and
then
on
the
next
slide.
J
The
The
Hub
will
distribute
that
back
out
to
to
all
the
other
servers
which
currently
only
includes
Alice.
So
it
also
goes
back
to
Alice's
clients,
and
then
we
head
into
the
actual
MLS
bits
so
I'll
hand
it
off
to
Conrad.
For
this,
where
I
think
he'll
be
able
to
cover
that
in
a
lot
lot
more
detail
than
I.
E
I
This
doesn't
resemble
at
all
what
I
thought
we
agreed
on
in
the
last
couple
of
calls.
I
think
what
we
discussed
was
that
this
purple
signaling
would
happen
simultaneously
with
the
endend
encryption
or
could
happen,
or
most
likely
would
happen
simultaneously
and
not
as
a
not
as
this
happens
first
and
then
happen.
Second.
E
No
good
good
point
I
was
I
was
starting
to
get
to
that.
So
we
here,
we
chose
the
kind
of
the
external
commit
based,
adding
Bob
flow,
where
a
lot
of
non-mls
stuff
happens
before
Bob,
then
kind
of
inserts
themselves
or
inserts
themselves
into
the
group
in
the
welcome
based
flow.
The
AL
will
probably
send
the
welcome
together
with
the
hey
at
Bob
signaling
message.
E
We,
we
kind
of
chose
this
presentation
to
show
kind
of
the
signaling
route
first
and
then,
if
you
go
to
the
next
slide,
we
start
seeing
Bob's
server
kind
of
the
Hub
sending
a
group
info
to
Bob
server,
and
this
could
be
the
Hub
could
send
the
group
info,
along
with
the
Bob
invitation,
signaling
message
to
Bob
server.
If,
if
that
is
if,
if,
if,
if
that
is
desired,
I
guess,
but
for
now
we've
kind
of
modeled
it.
We
we've
wanted
to
show
it
separately.
E
So
this
is
the
the
kind
of
MLS
part
at
work.
Bob
needs
a
group
info
to
join.
The
group
note
that,
like
as
a
small
kind
of
side,
the
group
info
has
to
be
current,
so
while
the
Hub
could
send
the
group
info
along
with
the
signaling
message,
if
Bob
is
offline
for
a
for
for
a
while,
and
the
group
evolves
in
the
meantime,
but
would
have
to
get
it
a
fresh
group
INF
for
anyway
to
join
externally.
E
E
E
B
C
C
B
H
Okay,
yeah
so
I
guess
maybe
I
just
don't
have
it
all
booted
in
my
head,
but
I'm
like
somewhat
uncomfortable
with
this
notion
that
the
Hub
is
doing
a
bunch
of
enforcement,
MLS
inv
variance.
That
seems
like,
like
maybe
that's
possible,
but
that
seems
like,
like
I,
like
none
of
these
documents,
had
rules
anywhere
near
clear
enough
to
implement
a
hub
in
order
to
do
that.
As.
H
H
Give
give
to
one
example:
I
mean
you
know,
you
know,
I,
add
somebody
but
I,
add
somebody,
but
I
give
them
key
material,
which
is
bogus.
It's
like
in
fact,
or
not.
Member
of
the
group
right
and
and
going
back
to
the
discussion
we
had
earlier
until
they've
actually
responded.
Then
they're
in
the
some
Lial
state,
where
nobody
sitation
is
and
the
how
have
enforce
that.
E
H
No,
no,
no
right
right,
but
but
I
guess
by
by
my
point,
is
that
the
the
MLS
state
in
the
M
right,
exactly
that's
that's
part
I'm
getting
at
is
like
is
like
to
what
extent
what
is
the
Hub
verifying
the
stuff
doing
like
what
is
the
function
that
Hub
verifying
stuff
is
doing
in
this
protocol?
What
happens
if
it
just
doesn't
do.
E
H
E
So
for
now
the
Hub
is
mostly
verifying
that
the
participant
list
is
injected
into
the
group
state
in
one
way
or
another,
by
whoever,
like
after
the
Hub
after
a
signaling
event,
has
reached
the
Hub
and
the
Hub
has
kind
of
blessed
it
and
F
it
out
to
everyone
else.
Then
it
requires
that
kind
of
it's
reflected
in
the
group
that,
in
in
my
I
I
like
to
think
of
the
the
signaling
messages,
as
you
can
Implement
them
using
proposals
right.
E
It's
just
like
Fanning
out
a
proposal
and
then
before
you
you
know
the
next
commit
has
to
implement
like
has
to
commit
to
that
proposal,
and
the
Hub
will
not
accept
any
other
commits
that
do
not
include
this
proposal
and
like
what
we're
doing
right
now
to
kind
of
keep
the
signaling
somewhat
separate
from
MLS
like
for
now
is
that
we
kind
of
yeah.
We
might
reinvent
some
properties
of
proposals,
but
yeah
I.
H
E
That
it's
to
ensure
that
everyone
agrees
who's
on
who's
on
the
participant
list
and
to
avoid
these
kind
of
weird
splits
where
someone
one
group
member
doesn't
think
Bob
is
in
the
group
and
the
other
one
does
think.
Bob
is
in
the
group
and
then
suddenly
Bob
joins,
and
one
group
member
will
think
that's
illegal
because
Bob's
not
on
the
participant
list
and
another
group
member
says:
oh
that's,
fine
Bob
is
on
the
participant
list
and
so
agreement
on
the
participant
list
is
vital
to
enforce
policy.
E
C
Richard
I
I
I
was
gonna
uplevel
this
a
little
bit
note
that
at
least
mechanistically.
This
is
not
a
crazy
ask.
So,
like
the
a
lot
of
the
reason
we
have
a
central
Hub
to
start
with
is
so
that
it
can
act
as
an
Arbiter
for
which
commits
get
applied
so
provide
the
sequencing
that
MLS
requires
at
a
base.
C
E
And
then
everyone,
like
everyone,
disagrees
with
that
commit
discards
it,
but
the
epo's
been
registered
forward
and
now
the
hub's
in
a
in
a
like
in
a
state
that
the
clients
are
not
in
and
like
that's.
So
we
try
to
do
I,
guess
a
lot
like
as
much
verification
as
we
can
to
on
the
on
the
hubset.
But
I
I
agree
that
we
need
to
write
this
down
formally
and
and
spell
out
what
security
guarant
these
weeks
back.
E
Sorry,
okay,
yeah
I,
think
I
think
this
is
the
end
of
the
first
flow
Richard.
If
you
could
SL
go
to
the
next
slide,
oh
yeah
I
mean
pretty
much
so
Al
and
Bob
can
now
Converse
and
then
I
think
we
can
I
don't
know
Tris.
Do
you
want
to
say
something
more
on
this
slide
or
or
do
we
want
to
go
to
the
next.
J
Scenario:
yeah
I
mean,
after
all,
the
invite
stuff
happens.
Yeah
they
can,
they
can
finally
send
messages
to
each
other
and
normal
Els
operations
happen.
It's
worth
noting
that
the
signaling
side
of
things
so
when
Bob
is
in
the
sort
of
joined
State
there
if
Bob
adds
through
their
provider
another
client,
they
can
add
that
to
the
MLS
group
without
talking
to
signaling
at
all,
they
can
just
do
that.
They
can
also
remove
all
their
clients
or
one
of
their
clients
whatever,
without
impacting
the
the
signaling
side.
J
J
All
right,
so,
if
we
head
into
the
the
next
slide,
then
we
will
have
some
even
more
assumptions
based
off
of
the
previous
discussion
there.
So
in
this
particular
scenario
we're
building
on
top
of
what
we
just
established
so
there's
a
room
with
Alice
and
Bob
in
it.
There's
some
clients
for,
for
both
they're
able
to
converse
and
Alice's
server
specifically,
is
still
the
Hub
for
the
room
and
so
on.
The
next
slide
we're
going
to
see
that
Alice
actually
wants
to
leave
that
that.
F
J
So
this
starts
with
a
signaling
event
again
and
again
like
this
can
also
be
stapled
together.
Both
the
the
DS
and
signaling
operations.
We've
just
split
them
out
here
for
at
least
visibility
purposes,
but
there's
nothing
necessarily
constraining
it
to
be
separate
operations.
They
could
be
at
happening
at
the
exact
same
time
here,
but
yeah,
starting
with
the
signaling
Alice,
generates
a
leave
event
sends
that
to
The
Hub
server
or
their
own
server,
and
then
on
the
next
slide.
J
We
again
use
that
secure
Channel
but
as
as
the
leave
event
is
being
found
out,
The
Hub
needs
to
require
that
all
of
Alice's
devices
are
actually
leaving
the
the
the
group
here,
because
Alice
has
no
right
to
to
continue
in
the
MLS
group.
Now
that
they're
evicting
themselves
from
the
from
the
over
or
the
from
the
the
room
as
a
whole.
J
So
on
the
the
next
slide
here,
I
think
we
had
a
a
minor
color
coding
issue
or
no
I'm,
just
not
staying
in
sync,
all
right,
so
yeah
so
Bob
receives
the
the
leave
event
from
from
the
server
that
was
found
out
from
the
Hub
and
then
on.
The
next
slide
we
start
to
get
into
the
into
the
MLS
side
of
things
for
Conrad
to.
J
So
now
they
they
have
the
state
knowing
that
they
are
no
longer
in
the
the
room
and
that
all
their
clients
have
been
evicted
as
well,
which
is
good
news
for
them,
because
that
is
the
intention
that
they
wanted.
So,
on
the
next
slide,
we
have
a
a
bit
of
a
constraint
here
where
you
know
it
is
no
longer
hello
world.
They
can
no
longer
communicate
with
each
other,
at
least
in
this
this
room.
J
But
there
is
the
the
interesting
point
that
Alys
server
is
still
technically
the
Hub
for
this
room,
but
they
don't
really
have
a
a
stake
or
anything
in
that
room,
so
we
may
or
may
not
need
the
server
or
the
Hub
server
Ro
to
transfer
of
some
variety
to
another
server.
But
this
is
something
that,
like
the
design
team,
hasn't
had
a
lot
of
opportunity
to
discuss.
Yet
so
it's
it's
kind
of
up
in
the
air,
we'll
kind
of
we'll
have
to
figure
it
out.
J
C
It's
clear
that
Bob
needs
to
do
the
commit
and
I
suppose
that
in
principle,
if
you
just
kind
of
announced
that
the
that
Alice
had
left
and
her
devices
needed
to
be
removed,
you
could
kind
of
let
Bob
and
Charlie
decide
on
their
own,
whether
they
want
it
to
commit
and
just
kind
of
throw
it
out
there.
What
gets
committed
gets
committed
it's
up
to
the
hub
to
to
decide
or
in
principle
The
Hub
could
designate.
C
E
E
The
Hub
should
require
that
the
next
incoming
commit
should
remove
Alice,
because
otherwise,
if
Alice,
you
know,
stays
in
the
group
as
a
with
kind
of
weird
clients
where
a
new
new
user
joins
the
group
or
new
yeah
user
joins
a
group,
adds
a
client
and
then
sees
oh
there's,
Alice
Alice's
clients,
but
Alice
is
not
on
the
user
list.
So
what
does
this
mean
like?
Who
is
Alice
yeah,
so
I
think
the
Hub
should
require?
Whoever
does
the
next
commit?
E
K
Yeah
I
have
a
different
question:
I
mean
the
flow
that
you
mentioned
here.
Kind
of
seems
the
opposite.
What
we
intro
introduced
earlier,
like
where
we
talked
about
removing
the
alysis
clients
first
and
then
removing
her
from
the
group
I'm
wondering
if
that
was
kind
of
a
conscious
decision,
or
there
are
technical
limitations
that
we
couldn't
go
down.
That
path.
J
Perspec,
it
doesn't
really
matter
whether
Alice
finds
a
way
to
sort
of
self-
evict
first
from
the
MLS
group
or
evicts
from
the
signaling
side.
First,
it's
just
laid
out
as
signaling
first
in
the
the
diagrams
here,
mostly
to
have
consistent
ordering
between
the
two
scenarios,
but
like
I,
like
I,
introduced
in
the
original
flow
there
like
th.
This
could
happen
simultaneously.
It
could
happen
in
a
different
order.
J
K
Well,
I
mean
the
reason
is
like
if
we
have
the
user
leave,
but
their
clients
are
still
in
then
the
room
is
in
a
consistent
state
right
and
so
that
that's
you
know,
that's
why
we
kind
of
discussed
like
you
know.
You
can
always
have
the
user
as
a
participant
in
the
room,
but
you
can't
have
without
any
clients,
but
not
the
other
way.
E
C
Yeah
well
going
back
to
so
what
Basel
said.
I
thought
what
we
had
discussed
in
the
design
team
call
was
made
sense
where
the
signaling
message
in
advance
of
Alice's
clients
being
removed
would
not
actually
remove
Alice
from
the
participant
list,
but
rather
put
them
into
some
Nona.
You
know
some
exiting
state
where
they
would
be
marked
and-
and
you
know
that
might
be
part
of
the
the
trigger
that
says-
that
Alice's
devices
need
to
be
removed.
So
I
think
that
order
of
operations
does
need
to
be.
C
E
Joined
yeah
I
mean
that
that's
partially,
due
to
an
unfortunate
like
restriction
of
MLS,
where
Ellis
can
cannot
just
do
a
commit
that
removes
herself,
because
the
the
committer
needs
to
introduce
new
Q
material
and
alos
needs
to
be
removed
from
theou
group
cryptographically.
So
she
shouldn't
be
the
one
who
samples
the
new
C
material
and
injects
us
into
the
group,
and
so
partially
at
least
it
comes
from
there
as
well,
but
I
I.
Think
Richard's
proposal
is
a
good
one
and
that
we
should
keep
this
invariant
alive.
H
Eric
yeah,
yeah
I
think
that's
thanks
for
thanks
for
that
com.
I
think
that
was
exactly
sort
of
thing.
I
wanted
to
hone
in
on
is
it's.
The
invariant
that
was
supped
at
the
beginning
is
if
you're
in
that
you
can't
be
in
the
MLS
group
being
a
participant
right,
but
you
can
be
participate,
not
being
MLS
group
in
the
simple
way
that
basically
You'
been
you
haven't
yet
got.
H
Is
there
any
way
in
MLS
to
get
back
in
that
state
once
you
had
a
client
added,
namely
so
I
was
a
participant
and
I
added
a
client
and
my
like
explodes
you
know:
is
there
any
and
I
no
have
a
new
phone
yet?
Is
there
any?
Is
there
any
way
in
this
infrastructure
to
get
back
to
the
once?
You'
ever
had
a
client
added
to
become
a
clientless,
an
inactive
member
of
the
group.
Or
can
you
only
go
from
inactive
to
active?
You
see
what
I
mean.
E
I
mean
you
can
go
from
from
active
to
inactive
if
you
just
propose
I
guess
if
you
have
a
different
semantic
for
the
whole
user
leaves
versus
the
user.
Just
has
his
last
CL
or
their
last
client.
Remove
itself
like
propose
a
removal
like
this
is
the
example
that
Matthew
I
think
you
you
brought
up
with
the
browser
tab.
I
want
to
close
my
browser,
tab
and
I.
E
Don't
have
any
other
client
but
I
still
kind
of
want
to
be
in
the
group
and
I
want
to
be
able
to
rejoin
the
group.
Without
you
know
having
to
having
to
have
someone
reinvite
me
I
still
want
to
be
authorized
to
be
in
the
group,
and
so
when
I
close
the
browser
tab,
it
sends
sends
a
leave
proposal,
and
so
the
next
person
then
kind
of
removes
the
browser,
client
and
then
I'm
still
I'm
in
the
next.
Is
that
what
you
meant.
H
Yeah
I
I
think
so
yeah
yeah,
because
I
mean
I
just
wor.
Is
there,
like
so
I,
think
that
like
do
we
wanna,
it
seems
weird
not
to
not
to
preserve
that
invariant,
but
maybe
it's
okay,
I,
don't
know
like
I
mean
I.
Think
I
like
this
browser
tab
example,
because
it
seems
like
good.
It's
like
a
good
security
practice
to
you.
H
H
C
G,
to
kind
of
pivot,
away
from
the
the
examples
to
kind
of
broader
discussion,
I'm
hopeful
that
at
least
a
few
folks
have
reviewed
the
documents.
In
addition
to
the
framework
we've
discussed
here,
if
you've
done
both,
you
can
see
there's
a
little
bit
of
a
disconnect,
so
I
think
the
question
for
the
working
group
here
is
you
know
if
we
think
about
what
stuff
we
would
want
to
adopt
to
start
getting
working
on
a
protocol?
Are
we
headed
toward
the
right
foundations
here?
C
F
So
I
basically
really
appreciate
the
work
that
the
design
team
has
done
to
try
to
accommodate
this
slightly
controversial
idea
of
a
transitional
approach,
We've
Ended
up
working
with
a
lot
of
the
big
messaging
providers.
Whilst
this
has
been
going
on
in
parallel
and
the
feedback
we've
had,
there
has
been
pretty
positive
in
terms
of
something
that
would
work
both
transitionally,
whilst
also
making
sure
everybody
can
end
up
on
mls.
F
H
C
H
H
I
spent
the
time
trying
to
read
them
and
really
felt
like
really
felt,
was
really
really
difficult,
so
so
well,
I
think
you
know
I
think
this
is
the
right
direction.
I
think
you
maybe
it
be
appropriate
to
to
option
call
for
the
Mimi
architecture
document
the
other
documents
using
a
lot
of
work
for
R
for
adoption.
H
You
know,
and
the
bar
has
to
be
like
you
persuade
yourself,
you
could
implement
this,
maybe
with
open
issues
as
opposed
to
sort
of
being
a
collection
of
open
issues
which
is
really
what
these
documents
feel
like
in
many
ways.
So
I
guess
what
I
would
encourage.
I
guess
I'd,
be
I'm,
happy
to
find
more
detailed
reviews,
but
but
I
think
I
think
we
need
at
least
one
more
of
the
documents
before
we
do
ad
option
for
anything
other
than
maybe
Mimi,
Arch
and
and
I.
H
Think
against
that
be
against
that
bar
against
the
bar,
like
they
should
be
self-contained,
I,
think
and
just
to
go
saying
earlier,
I
think
like
we
should
look
at
merging
them
pretty
substantially.
It's
just
really
hard
to
read
them
when
it's
like
this
thing
is
like
Point
thing
over
here
and
this
thing
over
here
and
like
and
like
it's
really
hard
to
know.
Is
this
just
not
defined
anywhere
or
is
it
defined
like
in
some
other
document,
and
no
nowhere
is
Ty
complete
the
answer,
but
but
it's
just
just
extremely.
C
And
for
for
avoidance
of
doubt,
I
think
that,
like
I
I
feel
pretty
kind
good
about
the
direction
we've
got
into
in
the
design
team.
I.
Think
eer
is
probably
right
that
we
need
one
more
spin
of
the
actual
documents
before
we
do
an
adoption
call,
but
I
think
we
can
probably
do
that
in
in
another
couple
weeks
get
thing
you
kind
of
take.
What
we've
discussed
here,
make
the
documents
a
little
more
concrete
and
put
something
forward
to
the
working
group
that
would
be
in
a
more
or
less
adoptable
shape.
A
A
F
A
Do
it
later,
because
that
feels
like
messy
so
I
would
I
would
like
to
understand
whether,
like
people
are
committing
to
that
and
how
that's
going
to
work
from
my
own
reading
of
them,
I
feel
like
that
could
be
quite
beneficial.
I
feel
like
there's
a
lot
of
inconsistency
across
them
and
they
feel
very
much
like
they
were
authored
by
different
people
separately.
A
G
In
yeah
speaking
as
I
guess,
a
working
group
member
and
not
a
chair
on
the
topic
of
like
document
consolidation,
I'm
very
much
in
favor
of
consolidating
them
like
over
in
the
distributed
aggregation
protocol
which
I'm
working
on
in
the
PPM
working
group.
We
have
a
split
there
where,
like
one
document,
is
in
the
PPM
working
group
and
then
it
relies
upon
another
document
called
VAP.
That's
in
cfrg
so
like
that
split
makes
some
sense,
because
it's
across
different,
like
working
groups
or
I,
suppose
working
in
research
groups,
but
all
of
a
say.
G
We
found
it
to
be
like
significant,
just
admin
overhead
having
these
two
drafts
to
Wrangle
and
there's
been
at
least
one
case
where
we
messed
up
the
submission
of
a
draft,
because
we
forgot
to
bump
a
version
number
and
whatever
so.
Multiple
documents
is
really
just
a
lot
of
tedious
admin
overhead,
especially
when
it's
not
clear,
but
it
provides
a
big
benefit,
so
I
heavily
favor
having
fewer.
E
Yeah,
okay,
sorry
yeah,
if
I
can
maybe
respond
to
that,
at
least
for
the
and
I
wrote
this
in
in
the
chat
earlier,
at
least
for
the
Mimi
DS
I,
think
it
would
make
sense
to
have
it
as
a
separate
document,
because
I
mean,
as
as
we
all
know,
and
and
I
mean.
That's.
Why
we
hear
is
that
MLS
is
not
sufficient
to
to
do
messaging
in
any
way,
shape
or
form.
J
Travis
yeah,
so
as
the
author
of
both
the
policy
and
signaling
documents,
I
I
think
those
two
spe
specifically
can
be
merged.
Quite
quite
easily.
Transport
might
be
a
little
bit
more
difficult
just
because
both
the
DS
and
remaining
portions
of
the
stack
need
a
transport,
but
it
is
possible
that
that
could
be
say
Amalgamated
into
more
of
a
Mimi
protocol,
stack
the
DS
kind
of
on
the
side.
J
B
H
The
subsections
of
the
document,
I
guess
like
the
like
I'm,
just
like
really
I,
guess
like
I',
be
more
I'
more
open
to
this.
Someone
showed
me
a
treatment
that
like
actually
was
readable
and
was
demounted
in
that
way,
but
like
right
now,
it's
like
incredibly
hard
to
follow
and
and
and
the
most
important
thing
is
to
be
readable
for
this
purpos
of
working
group
so
like.
A
B
A
C
B
A
Back,
okay,
I
think.
The
other
thing
is
you
know.
Some
of
some
of
the
documents
have
still
have
like
external
references
to
what
some
of
the
content
should
be
and
I
feel
like
for
the
purposes
of
adoption.
That
really
needs
to
get
filled
in
like
even
if
you
even
there's,
like
you
know,
whatever
placeholder,
to
do
like
you
haven't
decided
on
the
design.
A
A
Well:
okay,
now
we're
just
going
down
my
my
list
of
pet
peeves
as
I
was
reviewing
the
documents
so
I'll
go
to
the
next
one,
which
is
you
know.
We
had
I
think
a
good
discussion
today
about
the
the
integration
with
MLS
and
and
like
flexibility,
for
people
to
go
off
and
do
their
own
thing.
If
you
have
an
MLs
shaped
hole,
so
I
thought
the
discussion
was
good,
I.
Think
again.
A
But
I
think
we
also
need
to
kind
of
ditch
the
language
about
how
we're
doing
it.
Purposefully
to
you
know.
Let
people
use
other
encryption
protocols
like
it's.
It's
not
going
to
be
timeless
and
the
rfc's
once
they
get
published,
never
change,
so
we
should
take
out
all
the
stuff
which
is
kind
of
like
in
the
current
context.
Here's
what's
happening
and
just
say
say
what
we're
specifying
and
then
specify
it.
So
that's
my
other
piece
of
feedback
on
the
Ed
torial
changes
to
be.
F
F
That's
reasonable,
although
it
does
tie
into
the
previous
point
of
consolidation
that
I
was
to
Echo
the
desire
for
the
Mimi
DS
style
end
to
encryption
block
to
be
a
separate.
Spec
almost
helps
articulate
that
interface
for
the
Unspeakable
people,
who
might
want
to
swap
out
that
Lego
brick
for
equivalent
Lego,
shap
or.
F
Hole
as
it's
easier,
if
that
is
actually
a
hole
with
an
interface,
it
can
be
swapped
in
and
out
so
B
I
totally
agree
that
there
should
be
more
consolidation
and
I
agree
with
eeka
that
the
current
set
of
documents
are
indigestible
when
swallowed
as
a
whole.
I
think
there
there
is
an
argument
for
keeping
that
one
more.
C
B
B
H
Are
you
constantly
trying
to
remember
what
the
properties
of
the
DS
are
in
order
to
read
the
rest
of
the
document
and
then,
like
that's
bad,
and
if
the
the
properties
are
like?
No,
like
you
have
a
vague
sketch
of
what
the
DS
does
and
then
like
read
the
document,
then
that's
like
cool
but
like,
but
if,
like
there's
like
a
lot
of
back
and
forth
in
between
them,
it's
just
like
like
makes
it
really
hard
to
read.
F
I
guess
it's
possible
that
the
DS
boundary
specifically
isn't
the
right
one,
it's
more
the
different!
Well,
it's
the
MLS
shaped
hole
which
has
some
overal
out
with
Ds,
but
also
the
confirmation
Primitives,
for
instance,
made
available
to
keeping
the
participant
list
in
the
room
state
in
sync,
with
the
underlying
encryption
group.
F
So
I
I
agree
with
AKA
that
you
shouldn't
be
sitting
there,
thinking
what
the
hell
is
a
DS
and
what
is
it
doing
right
now,
but
it
might
not
be
that
bad
abstraction
to
be
thinking
and
now
I
what
the
equivalent
would
be
for
that
slightly
high
level
abstraction.
It
doesn't
solve,
of
course,
Conrad's
concern
about
having
MIM
DS
as
a
standalone
thing
that
can
be
used
as
a
pure
MLS
DS
irrespec
of.
E
Mimi
yeah
I
think
I
think
those
are
all
fair
points
and
all
I
can
really
say.
Is
that
sure
we'll
we'll
give
it
a
try
and
if
it
doesn't
work
the
M
media
section
will
then
I
guess
just
become
a
subsection
which
can
easily
be
done?
I
guess
so
yeah
we'll
we'll
give
it
a
go
and
you'll
you'll,
you
know
be
the
judge
of
if
it
worked
or.
A
Not
sounds
good,
then.
My
next
question
is
about
the
architecture
document.
If
you
want
to
keep
that
separate
and
that
one's
been
around
longer
I
know
it
got
updated,
but
if
we're
keeping
it
separate,
we
could
sort
of
PLL
for
adoption
today
and
confirm
on
the
list.
But
if
you're
going
to
fold
it
in
then
we
won't
do
that.
B
C
I
think
yeah
I
would
probably
keep
it
separate
in
the
same
sense
that,
like
MLS,
did
an
architecture
protocol
distinction,
as
in
that
case
also
there
is,
there
will
be
some
overlap
in
terms
of
overall.
You
know
the
overall
logic
of
how
the
thing
operates.
They'll
have
some
overview
of
that
in
the
protocol
document
to
warm
people
up,
but
also
describe
that
in
the
architecture.
C
H
I'm
not
sure
I
have
strong
feelings
either,
but
I
would
probably
merge
it.
I
think
I
think
I
mean
I,
think
it
Ser
as
a
nice
as
a
nice
introduction
to
Consolidated
document,
which
I
think,
like
largely
in
much
respect.
I
think
may
have
been
better
other
context
too.
So
again,
I'm
not
gonna
like
fight
strongly
on
it,
but
I.
Think,
like
the
question
is
like
how
much
material
we
end
up
duplicating
the
question.
Is
you
need
to
read
the
architecture
document
order?
A
I
A
Reason:
okay,
I!
Think:
oh
Rowan,
are
you
back
in
the
queue
okay,
I
think
I
mean
given
that
that
you're
going
to
go
back
and
and
do
a
spin
of
the
others
we
can.
We
can
revisit
this
next
time
when
those
when
those
are
done
and
if
we
want
to
do
separate
documents
and
separate
calls,
then
we
can
do
it
at
that
point.
I,
don't
think
we
to
do
it.
A
A
Okay,
I
was
looking
at
the
the
doodle
poll
results
and
I
think
we
have
a
couple
of
dates
in
October
that
are
looking
kind
of
good,
maybe
October,
10th
and
19th.
So
I'm,
assuming
10th,
is
too
soon
to
come
back
to
this
topic,
but
feel
free
to
get
in
the
queue
and
tell
me
that
I'm
wrong.
So
if
we
schedule
those
two,
then
probably
the
10th
will
come
back
to
discovery,
which
we
have
lots
more
to
talk
about,
and
then
19th
come
back
to
this.
A
But
of
course
like
send
us
the
documents
whenever
they're
ready,
so
people
can
review
and
we
don't
have
to
have
a
meeting
in
order
to
to
move
forward,
but
it
could
be
a
good
demarcation
point
to
get
that
moving
again.
That's
kind
of
my
thinking
does
that
sound,
okay,
okay,
Richard
says
it's
good.
All
right,
I,
don't
think
I
have
anything
else.
Tim.
Do
you
have
anything.