►
From YouTube: IETF94-CLUE-20151104-1030.webm
Description
CLUE meeting session at IETF94
2015/11/04 1030
A
A
We
will
start
with
the
status,
update
and
status
of
blue
protocol,
clue,
signaling,
the
mapping
RTP
stream
to
chlamydia
captures
and
we'll
have
also
shot
a
citation
of
usage
of
clewis
perk,
which
will
also
be
presented
in
because
it
is
basically
was
for
a
perk
document
document
status,
clue
framework
here
in
jack.
In
the
version
23,
this
version
tried
to
address
the
security
comments
from
the
ad.
We
need
to
wrap
it
up.
A
There
is
a
current
text,
change
that
we
probably
would
make
will
make
in
the
document
which,
to
reference
to
address
the
issue
of
what
security
should
will
use,
because-
and
the
point
was
that
the
consensus
in
the
working
group
was
that
we
don't
want
to
have-
must
use
dtls
srtp,
but
it
must
be
supported,
but-
and
there's
also
must
be-
some
must
be
some
other
security.
She
must
be
in
place,
but
there
can
be
other
ways
to
do
it
and
the
way
the
fix
that
we
want
to
to
have
is
that.
A
In
addition,
the
media
is
based
on
RTP
and
thus
existing
RTP
security
mechanism
should
be
supported,
and
this
pls
srtp
must
be
supported
and
should
be
used
if
media
is
protected
by
other
means
for
as
specified
in
RFC
7
examples
are
in
RFC
7201,
then
btls
srtp
doesn't
need
to
be
used.
So
this
is
the
proposed
text
tool
to
have
in
the
framework
document.
A
There
is
also
for
some
texture
to
be
put
put
base
comment
from
Alicia
about
the
security
for
the
clue.
Data
channel
and
crystal
is
up
to
date
on
that
he
was
part
of
the
discussion.
So
we'll
have
a
revision
on
that
and
that's
why
it's
probably
good.
We
didn't
send
it
yet
to
publication,
and
we
said
we
will
do
it
with
the
other
documents.
Even
though
it's
been
ready
for
a
long
time
that
the
data
channel
the
xml
schema
for
clue
data
model
in
the
11
graph.
A
A
A
A
C
Yes,
I
think
this
is
going
to
be
quite
quick.
Actually,
it's
just
a
minor
update
next
slide.
Please
we
submitted
to
two
new
versions.
04
was
basically
a
mistake
with
it,
because
there
was
some
text
from
the
previous
version,
the
nose,
the
which
was
not
up
to
date.
So
then,
in
few
minutes
we
submitted
the
last
one
that
is
version
05,
sorry
06,
and
basically
we
try
to
address
most.
If
not
all,
of
the
comments
that
we
get
rid
from
the
mailing
list
and
I
think
that
document
is
now
Oh,
quite
quite
stable.
C
The
only
things
that
we
have
to
discuss
are
in
the
next
slide
yeah.
Actually,
we
need
to
work
on
the
Security
section.
There's
no
security
considerations
in
the
document
now
we're
working
on
them
and
we
want
to
come
out
with
a
complete
as
as
thorough
as
possible
section
on
this.
We
are
taking
a
look
at
all
of
the
related
documents,
so
we
would
like
to
be
capable
of,
let's
say
summarizing
all
of
the
security
considerations
that
are
strictly
related
to
the
protocol
and
which
are
not
already
already
contained
in
the
other
documents.
C
C
Perhaps
we
love
to
add
some
more
detail:
it's
tape
machines
for
the
very
first
phase
of
the
protocol,
negotiation
that
is
associated
to
the
options
exchanging.
We
we
just
gave
for
granted
that
this
is
a
very
straightforward
face,
but
perhaps
we
can
add
some
more
detail
on
that
and
I
already
had
the
chat
yesterday
with
Dan
Burnett
to
volunteer
to
make
it
double
check
related
to
diapers
and
english
language,
and
so
on
and
so
forth.
Ok,.
A
C
D
C
A
D
A
C
A
Okay,
so
now
we
are
in
the
queue
signaling
Rob
Rob
made
the
slides
for
for
that
and
send
them
I'll
try
to
present
it.
So
since
ITF
93
version
06
produced
and
put
into
a
new
class
called
made
consistent
with
data
model
and
protocol
documents,
terminology
matches
the
framework
dtls
mandatory
to
implement,
but
no
longer
mandatory
to
use
security
mandatory
to
use
but
no
longer
defined
as
a
srtp.
This
has
to
be
in
like
this
has
to
be
in
line.
A
This
has
to
be
in
line
with
the
framework.
They
will
need
to
see
that
did
not
conflict,
because
the
signaling
is
the
part
that
does
the
the
SDP
part
of
the
update,
odd
negotiation.
So
it
should
be.
Have
the
right,
the
right
security,
their
limited
syntax,
of
a
Geo
264
encoding
on
send
only
M
line
removed
as
an
open
issue.
A
A
A
E
A
A
Okay,
so
there's
no.
Is
anyone
going
to
do
a
review
by
still
this
month
or,
if
not
that's
what
he
says
he
submitted
version
and
we
probably
will
do
we
do
after
the
changes
would
do
another
review
to
to
verify,
but
I
think
they
we
had
so
far
the
reviewers,
the
reviewers
so
far,
so
it's
it's
in
good.
At
least
we
got
good
reviews
for
the
document
because,
like
he
mentioned,
christian
Paul
and
Mark
were
involved
in
this
work
did
review
that.
So
we
had
a
good
good
look
at
the
document.
A
Anyone
here
is
that
is
nothing.
This
ok,
so
I
assume
that
they're
not
there's
no
incoming
reviews,
so
we'll
have
another.
So
you
can
do
another
revision
and
then
we
will
also
will
go
to
another
working
group
last
call
to
finish
the
document
and
Seneca
publication,
so
this
is
also
in
the
same
timeline
as
the
protocol
right
because
he
said
about
the
end
of
the
month.
So
it's
the
same.
A
B
So,
coming
back
to
this,
the
issue
about
securing
the
signaling
I,
actually
don't
think
what
we
have
now
proposed
for
the
framework
and
what
it
says
in
the
signaling
or
actually
what
it
said
in
the
slide
are
exactly
the
same.
So
what
it
said
in
the
slide
was
dtls
mandatory
to
implement,
but
not
to
use
security
mandatory
to
use,
but
in
the
document
it
says
all
clue,
control
the
M
lines
must
be
secured
and
implemented.
Lowercase
must
oku.
D
B
If
it's-
and
this
is
actually
probably
where
my
initial
confusion
came
about
in
my
in
my
comment
on
the
framework
document,
if
its
security
mandatory
to
use,
then
it
should
say
that
normatively
and
it
should
also
say
that
in
the
framework
it
doesn't
say
that
in
the
framework
right
now.
Okay,
so
is
that
what
the
decision
was
the
in.
A
The
frame,
but
I
think
what
what
the
decision
coffee
is,
what
the
facts
that
I
put
on
the
on
the
on
the
slides
on
the
status
about
the
from
from
day
from
the
from
the
framework
on
the
framework,
I
will,
I
will
look
at
the
Security
section
signaling
and
proposed
correct
text
to
be
doing
them
in
line.
So
since
I
I
wrote
most
of
I
did
the
latest
changes
in
the
framework
I'll.
Do
it
the
same
here
in
the
signaling
in
house
and
I'll
send
text
to
the
list
for
revising
that?
Ok,.
D
D
D
A
B
This
yes,
but
that
so
that's
not
the
same
thing
that
you
just
said,
because
you,
because
you
said
you
think
the
framework
is
there
correct
yeah.
What
has
been
proposed
for
framework
is
correct,
and
what
he's
saying
is
that
he
thinks
what
what
if
taking
the
language
in
the
signaling
document
as
normative.
He
thinks
that
is
correct.
No.
A
B
E
Let
me
just
be
clear
unless
I
believe
what
you're
saying
is
that
capitalization
or
not
the
text
that
is
in
the
signaling
document
does
not
match
what
is
in
the
framework
document
and
if,
what's
in
the
framework,
talk
is
what
we
say
is
normal
is
is
correct.
Then
the
text
and
the
signaling
document
needs
to
change.
I.
B
That
is
true,
I
guess
ocean.
My
my
point
is
that
there's
the
substantive
difference-
it's
not
just
about
the
you
know
what
that
meant
to
be
normative
or
not.
If
it
was
intended
to
be
normative,
it's
a
different
requirement
than
what
is
expressed
in
the
framework
and
if
there's
a
difference
of
opinion
about
what
you
what
it
should
be,
then
that
needs
to
be
resolved
right.
A
A
A
It's
not
the
same
text,
because
we
have
some
some
things
that
are
different
in
our
this
way,
but
it's
based
on
that
in
terms
of
the
issues
that
it's
discusses
and
the
other
part
of
the
document
that
it's
a
in
order
to
associate
the
media
in
the
different
protocols,
the
different
protocols
mean
the
SDP
and
the
clue
protocol.
There
are
three
mapping
that
needs
to
be
specified.
The
clue
individual
encoding
to
sdp
done
using
the
label
attribute
the
RTP
media
stream
to
sdp.
A
This
is
not
a
clue,
specific
method
for
done
bundle.
It's
done
using
SDP
media
tribute
and
there
are
specific
clue,
mapping
that
need
to
be
done
with
the
RTP
media
stream
to
media
captures
to
map
the
received
RTP
stream
to
the
current
M
media
capture
in
the
MCC,
and
this
is
a
new
attribute
defined
in
the
in
this
document.
This
is
not
new.
It
was
also
in
the
previous
version.
A
A
So
for
mapping
RTP
media
stream
to
media
capture
for
mapping
in
RTP
stream
to
a
specific
media
capture
in
the
MCC,
the
Klu
Klu
capture
I
did
specify
this.
What
I,
men
and
the
media
center
must
send
for
MCC
the
capture
ID
in
the
RTP
header
and
as
an
RTC
p.s.
This
message
and
the
document
defines
this
to
two
extensions.
The.
A
A
This
document
is
referenced
by
the
framework
also,
so
it
is,
but
it
is
part
of
the
documents
so
so
to
conclude,
the
current
state
of
the
of
the
working
group
before
I
mean
this
is
all
about
the
mapping
other
any
question
about
mapping
so
so
to
to
look
at
this
current
state
of
the
before
we
go
to
the
perk
1,
which
is
not
specific
for
here,
just
to
look
at
the
current
state
of
the
working
group
document.
So
we
can
see
that
we
can
close
the
working
group.
Eventually,
we
have
the
clue
data
channel.
A
The
crystal
document
is
just
needs
now:
some
revision
about
the
security
that
it
needs
to
change
and
otherwise
there's
no
changes
there.
The
data
schema
is
ready
for
publication.
Basically,
the
protocol
and
signaling
we
discussed
today
or
their
good
chef
will
have
a
new
revision
by
the
end
of
the
month
and
will
do
work.
A
new
plus
Colin,
try
to
finish
with
them
and
I'll.
The
mapping
will
try
to
do
the
same
thing,
also
to
try
to
finish
the
missing
part
and
to
do
it.
A
The
netting
is
the
only
one
that
didn't
go
here
through
any
working
group
last
call,
while
the
other
did
the
working
group
last
call.
So
we
are.
We,
hopefully
also
will
be
able
to
finish
that
this
year,
also
the
mapping
document
and
that's
probably,
all
the
documents
we
have
in
the
working
group
for
in
order
to
finish
the
work.
A
D
F
D
A
Of
them
at
the
same
time,
yeah
we
try
to
do
that.
The
same
time,
okay,
I,
hope.
Also
the
mapping
I
mean
at
least
the
first
four
we
will
try
to
to
do.
At
the
same
time,
the
reason
we
were
holding
the
document
so
because
there,
if
you
notice,
there's
cross
relations
between
them,
so
instead
of
sending
them
out
and
figure
out
that
we
need
to
change
afterwards,
we
wanted
to
have
them
all
at
the
same
time
and
finish
that
okay.
B
F
A
A
Okay,
so
efficient
Grove
was
try
to
initiate
to
start
a
document
about
the
use
of
clue.
We
spared
order
to
figure
out
what
is
the
requirement
that
we
have
specifically
for
clue
in
order
to
use
the
perk
solution
or
what
we
would
expect
from
perfect
tool
to
allow
us.
So
the
draft
is
the
initial
thought
around
the
perk
charter
item,
the
perk
which
is
being
promoted
by
both
seat
and
way
about
this
en
pointe
I'll
telepresence.
The
input
using
the
protocol
defining
the
clue
working
group
could
utilize.
The
defined
security
solution
need
to
be
considered.
A
However,
it
is
acknowledged
that
limitation
may
exist,
resulting
in
restricted
functionality
or
need
for
additional
adaptation
of
the
club
tottenham.
The
draft
seeks
to
identify
the
restriction
and
potential
adaptation
and
to
treat
your
father
discussion
draft
assume
that
the
MDB,
which
is
the
central
point
in
the
perk
architecture,
terminate
the
clue
and
access
reduce
function
MCU.
A
A
A
Both
s
DPM,
clue,
signaling
I,
required
to
establish
RTP
flow
bundle.
Srtp
can
be
used
with
clue.
The
clue
MCU
flow
so
clue
is
hop-by-hop.
The
MCO
act
as
an
aggregation
point.
The
MCO
modified
combines
clue
advertisement
according
to
capabilities
and
the
MCO
generate
clue.
Configured
figure
based
on
received
configuration.
A
D
A
It's
probably
it's
it's.
The
question
is
I
mean
the
major
question.
That's
part
of
the
thing
we
want
to
again
to
addressing
in
Perl
is
what
is
really
trusted
an
untrusted,
because
when
the
peg
talk
about
our
trusted
they're
saying
they
are
untrusted,
basically
on
the
media
on
the
media
itself,
so
the
media
itself
should
be
secure
end-to-end.
Now
they
want
to
have
some
minimum.
It
needs
a
minimal
information
in
order
to
be
able
even
to
switch.
F
A
F
Have
I
mean
it
certainly
valid
to
have
you
know
every
stream
set
discreetly,
you
know.
Basically,
it's
the
because
o
every
you
just
use
switch
captures
only
and
that's
you
that's
fun.
I
mean
it's
a
little.
It's
not
maybe
how
much
people
with
an
audio
but
for
video
I
think
it's
one
of
the
very
normal
use
cases
I.
A
C
D
A
The
MTD
can
only
provide
see
and
that's
what
what's
here
we
talk
about
topology.
The
mvd
can
only
provide
switching
topology
composition
that
supported
the
indication
on
clue.
Must
capture
up
to
build
and
multi-core
content
captures.
That's
what
it
means
in
terms
of
what
will
happen
in
clue,
because
you
won't
have
the
the
max
capture
which
allows
you
to
to
mix
and
beer.
A
The
mcc
policy
attribute
value.
Sound
level
can
only
be
used
with
unencrypted
m2m.
This
is
also
true
for
the
probably
for
the
perk
in
general,
because
you
use
the
max
the
sound
level
they
also
the
RTP
header
of
sound
for
doing
the
switching.
So
some
never
are
that's
what
he
is
saying
here,
so
that
there
is
that
the
mcc
which
allows
you
to
do
voice
activated
video
switch
modes,
which
is
the
more
the
trevor
relevant
here.
A
Media
manipulation.
The
MTD
kinetic
said
access
encrypted
media
therefore
cannot
verify
or
filter
out
and
buy
the
text
not
possible
to
transfer
images,
etc.
This
is
something
that
you
can
do
in
video,
which
is
a
sometimes,
and
you
may
do
it
in
telepresence.
I
have
embedded
pictures
inside
or
whatever,
and
you
can
take
it
in
evo.
If
you
look
at
the
the
information,
this
is
something
that
cannot
be
done.
It's
not
very
common
use,
but
it's
something
we
need
to
no
clue
empty.
A
Do
MDD
can
add,
captures
consumers
need
to
ensure
correct
authentication
before
configuring
this
capture.
So
this
is.
This
is
a
point
because
it's
also
true
I
mean
in
the
upper
case,
I
mean
you
have
to
be
authenticated
as
a
participant
in
order
to
get
the
keys
to
allow
to
add
media.
So
there's
nothing
contradictory
by
the
way
in
perk
to
say
that
dmdd
can
the
MV.
We
can
add
media,
ok,
but
it
means
that
it's
not
them.
A
A
Advertisement
may
not
want
MVP
to
have
access
to
this
information,
so
this
information
is
may
we
have
to
look
to
see
what
we
recommend
for
for
the
X
card,
which
was
also
an
issue
in
general
in
the
security
for
framework
about
what's
to
be
disclosed
in,
to
whom
clue
may
contain
proprietary
extension
make
on
may
contain
information
not
for
MDD
and
again.
This
is
something
that
need
to
be
specified
specifically
for
for
the
clue,
usage
of
rathbun
clue,
relation
to
perk
issue
to
encoding.
A
Clue
only
has
encoding
ID
used
for
correlation
to
sdp
and
max
betray
no
need
for
seem
to
add
perk,
specific
encoding
info
info
on
that
the
RTP
stream
to
chlamydia
capture,
mapping
RTP
an
RTC
PK
include
capture
ID,
so
the
MDD
will
need
to
model.
We
need
to
modify
our
Tea
Party,
City
and
crew
signaling
to
correlate
the
capture
ID.
So
that's
something
needs
to
be
addressed
also
as
part
of
the
parameters
that
need
to
be
accessed
so
change
by
the
by
the
mvd.
Yes,.
F
A
A
Potential
clue,
update
partially
encrypted
clue.
Advertisement
basic
structure
of
clue
advertisement
remain
only
potential
sensitive
information
is
encrypted.
M2M
information
within
capture
seen
similar
simultaneous
simpleton,
who
sets
people.
Media
capture
is
encrypted
clue.
Configures
unaffected
clue
option
unaffected,
so
he
was
just
trying
to
figure
out
what's
what
is
maybe
need
to.
We
can
do
in
clue
in
order
to
make
it
more
secure
to
have
less
trusted,
MDD
or
MCU
in
the
middle.
A
That
does
just
video
switching
as
in
this
case,
so
if
it
does
video
switching
based
on
just
on
sound
level,
some
of
this
information
is
not
so
relevant
to
the
MVP.
They
are
relevant
just
for
the
receiving
end
points,
so
it
can.
We
can
look
at
it
and
see
if
we
have
some
mechanism,
but
that's
something
for
later.
It's
not
part.
It's
currently
not
for
the
we're
not
going
to
do
it
currently
in
clue
as
if
we
close
the
working
group.
D
So
Stefan
mega
a
bit
of
brainstorming.
So
assuming
that
we
want
to
address
this
problem
at
all
which
I
don't
know
whether
this
is
viable,
so
one
option
is
what
he
came
up
with
partial
partial
encryption
of
the
stuff
which
this
Emmett
MBD
doesn't
doesn't
need.
Access
to
another
option
would
be
to
kind
of
run.
D
Two
parallel
clue
wish
I
hate
to
overload
the
word
session
one
more
time,
but
you
know
what
I
mean
right
so
so
to
run
basically
one
classic
end-to-end
clue
thing
which
can
be
completely
encrypted
and
then
have
a
redundant
one
which
a
limited
feature
set
that
those
times
you
get
that
talks
to
the
it
to
the
MDD
I
hate
to
use
the
term
MCU.
In
this
context,
because
most
people
associate
with
an
MCU
exactly
these
things,
which
an
MD
d
can't
do,
namely
video
mixing,
decided
you
mix
audio
mixing.
D
A
F
Know
yeah
I'm
drunk,
I
mean
I
think
topologically.
This
means
you
no
connection
to
the
KDF
and
a
connection
to
the
MDD
arm
or
something
at
least,
and
I
think
one
of
things
that
perk
hasn't
looked
at
yet
is
how
endpoints
do
you
communicate
with
the
KDF
and
I
think
there's
going
to
be.
You
know
a
lot
there
and
I
suspect
that
once
maybe
once
that
gets,
you
know
a
little
bit
more
solid
in
perk
who.
A
I'm
going
by
do
I'm
going
to
present
it
in
perak
also
because
I
think
I
think
the
point
that
Jonathan
made
about
that.
We
are
not
clearing
perk.
What
is
really
the
I
mean
what
how
the
signaling
work
and
how
you
connect
to
the
king,
which
you
should
know
about
the
roster
of
the
conference.
Then
then,
after
we
have
this
in
place,
we
can
understand
how
to
do
clue.
Is
that
this.
A
It's
not
just
the
Xcode
adjust,
for
example,
if
I'm
doing
video
switching
then
I
don't
care
for
the
all
the
information
in
the
clue,
for
example
the
size
of
the
factors
or
whatever
the
information
about
all
the
special
information.
It's
not
important
right,
so
it's
not
important
for
the
MVP
the
question.
It's
a
question
against
what
is
the
trust
level
you
want
from
the
right,
the
signaling
entity
in
the
middle,
what
information,
what
to
expose
to
it?
There
are
a
lot
of
information
in
the
that
is
not
relevant.
F
It
there's
like
three
classes
here
right:
there
is
information
that
isn't
relevant
to
the
MTT
in
which
we
know
it
is
related
privacy
right,
there's
information
that
the
MDD
doesn't
need,
which
is
perhaps
safe
to
leak
because
it
has
no
privacy
implication.
You
know
then
there's
a
third
set
of
MGD
just
needs
to
know
it.
Thank
you
I'm
not.
I
understand
that
the
X
cards
are
in
the
first
category
and
we
have
anything
else
in
the
first
category,
so
we
may
be
making
a
bigger
palm
of
this
than
it
actually
is.
A
F
D
A
Think
we
that's
why
we
see
submitted
the
document
super
because
he
will
we
would
like
to
do
it
currently
in
perkin,
we'll
see
that's
something
we'll
have
to
decide
later,
where
the
document
will
finish
with
it
on
we,
don't
we
don't
I,
don't
think
that
we
don't
want
to
add
a
new
work
item,
22
clue
and
to
finish
the
working
group
and
then
figure
out
how
to
do
this
work.
If
we
decide
to
go
on,
then
I
would
hate.
E
Let
me
be
very
clear:
there
is
in
fact
I
asked
running
this
question
also
before
today.
There
is
no
plan
for
this
document
to
become
an
official.
A
document
of
this
group
right
it
is,
it
is
being
submitted
to
perk
not
for
this
group.
There
is
no
intention
at
this
time
to
do
any
work
beyond
the
existing
documents,
which
we
plan
to
complete
and
just
to
say
it
again.
In
case
people
missed
it,
we
plan
to
complete
those
and
be
done
with
this
group
before
the
next
IETF
meeting.
Okay,
so
we
are,
we
are
finishing.