►
From YouTube: IETF109-CORE-20201120-0900
Description
CORE meeting session at IETF109
2020/11/20 0900
https://datatracker.ietf.org/meeting/109/proceedings/
A
A
A
E
B
F
A
A
A
A
A
Please
remember
the
note
well
applies
to
to
this
session
as
well
and
yeah.
I
mean
you
know
how
the
java
works
and
that
the
meeting
is
recording.
So
for
the
friday
session
we
have
well.
We
have
a,
I
think,
a
bit
of
a
shift.
We
will
have
the
adhoc
presentation
first
because
it
was
postponed
from
the
last
meeting
and
we
have
a
bit
of
a
short
update
on
some
of
the
drafts
that
maybe
marco
you
can.
You
can
give
the
update.
B
Sure
all
happened
yesterday,
actually
stateless
was
approved
for
publication
by
the
isg,
as
a
quick
check
from
ayanna
approved,
enter
the
editor
queue.
So
that's
great
thanks
to
the
authors
and
working
group,
and
also
two
other
drafts
are
now
in
last
call,
so
the
vrn
request
tag,
so
they
should
also
proceed
well,
hopefully,
in
the
coming
weeks,.
G
A
A
D
H
H
So,
at
the
last
itf
meeting
we
had
used
the
options
only
so
so
we
got
a
feedback
from
the
working
group
that
working
book
preferred
to
send
adoc
in
a
no-score
message
and
not
that
not
to
send
all
score
in
a
talk
message.
So
each
of
oscore
and
edok
define
how
to
send
an
oscar
or
a
message
over
co-op
and
we
went
with
send
adult
score
and
even
then
we
still
have.
H
Byte
next
slide,
please
so
just
to
remind
you
what
these
two
options
would
look
like
if
all
score,
if
addock
was
signal
in
a
new
option
you
can
see
here.
This
is
a
co-op
message,
figure
actually
and
educ
message.
Three.
The
data
and
your
cipher
text
are
in
the
payload,
so
there
are
sequence
in
the
payload
and
the
second
option
next
slide
is
to
take
a
bit
in
the
offer
option
itself.
H
H
We
got
58
bytes
in
total
for
the
cooperage
when
the
the
signaling
on
with
an
empty
option
and
57
bytes
in
total,
but
only
because
we
are
using
a
bit
in
the
flag
byte
that
doesn't
need
to
extend
the
flag
by.
So,
as
you
know,
we
only
have
eight
bits
in
the
fight
and
we
are
using
the
last
one
to
signal
oscar
plus
endoc
in
this
message.
H
So
next
slide,
please
so
on
our
way
forward,
we
still
have
as
a
goal
to
choose
one
of
the
alternatives
we
like
to
get
feedback
and
reviews
from
from
anybody,
and
hopefully
then
this
work
and
standardize.
It
and
it
will
be
a
very,
very
simple,
a
simple
document
once
we
have
chosen
so
johnny's
saying
in
the
chat
that
we
should
probably
not
use
the
last
flag
bit
better
to
say
that
for
other
stuff,
that
is
sent
in
a
message-
and
I
agree
so
basically,
the
difference
in
size
between
these
two
options
is
zero.
H
H
I
I
H
A
J
I
don't
know
I
I
could
think
if
you
use
a
new
option,
you
might
run
into
problem
if,
if
in
the
future,
there
is
some
second
option
that
also
want
to
add
things
and
concatenated
with
oscar.
Then
then
you,
if
you
use
both
options,
then
we
might
run
into
problems.
So
from
that
perspective
it
seems
maybe
a
little
bit
better
to
register
a
new
bit
in
or
score,
but
I
don't
have
a
strong
preference.
E
So
any
anything
that
prescribes
some
pre-processing
of
the
payload
before
getting
passed
on
to
before
becoming
the
message
that
would
be
there.
If
that
option
were
not
present,
will
need
to
solve
its
sequencing
issues.
That's
independent
on
whether
it's
inside
the
yet
hook
option
or
or
a
new
option
at
all,
sorry
inside
the
oscar
option
or
on
your
option
at
all.
A
H
So
really,
what
we're
looking
for
is
opinions
at
this
point
on
what
do
you
think
is
best,
and
if
anybody
wants
to
implement-
or
you
know
that's
obviously,
the
the
best
way
to
give
feedback
is.
Oh,
I
implemented
this
way
and
it
really
didn't
work
so,
but
I
personally,
I
personally
cannot
see
a
big
difference
between
these
two
options.
F
I
E
Might
be
able
to
just
register
it,
I
I
I
talked
about
that
with
ayanna
just
the
day
before,
and
it's
an
early
allocation
can
basically
be
done
by
the
work
through
the
working
group
chairs.
If
there
is
consensus
in
the
working
group
that
this
will
be
used
in
late
kind
of
that,
this
document
is
going
towards
is
going
somewhere.
I
A
Just
a
second,
let
me
interrupt
here
because
we
already
17-
and
I
don't
want
to
to
do
too
much
on
this
topic
right
now.
I
think
francesca
you
got
the
feedback
you
wanted
and
everybody
seems
to
be
leaning
towards
the
ad
hoc.
Can
we
do
the
rest
offline?
Is
that
okay,
so
that
we
can
continue
with
the
core
session
sure.
H
I
I
Well,
at
the
last
idf
we
said
we
needed
more
reviews
and
we
identified
two
people
who
will
be
doing
reviews
hello,
bill,
hello,
heimer
and
dash
one
was
submitted
recently.
There
are
just
minor
edits
there
with
an
updated
reference,
so
it's
essentially
still
the
same
document,
so
it
would
really
be
great
to
get
some
reviews
and
also
it
would
be
great
to
get
some
implementations
ari,
considered
implementing
it
before
the
meeting.
I
don't
know,
did
you
get
around
to
that.
K
K
I
C
K
K
I
A
So
I'm
next
in
the
queue
regarding
the
version
I
mean
regarding
the
draft,
I
actually
read
a
few
times.
It's
very
short,
I
just
I'm
sorry.
I
didn't
have
the
time
to
write
it
down.
The
feedback
is
I
mean
mostly
positive,
basically,
either
numbers
or
or
using
bit
fields,
it's
different
ways
to
represent
some
new
thing
new
feature.
I
Okay,
so
my
summary
would
be.
We
have
one
implementation
and
aria
if
you
can
write
a
sentence
or
two
about
that
to
the
mailing
list,
and
it
would
be
good
if
the
people
who
did
the
reviews
actually
also
write
something
to
the
mailing
list,
and
with
that
maybe
we
need
a
dash
or
two.
But
then
we
should
be
ready
for
a
new
glasgow.
A
L
A
I
A
I
I
So
this
draft
defines
a
content,
format,
indication
field
or
ct
field
next
slide,
so
in
in
this
example,
for
instance,
it
would
say
that
the
content
forward
is
c-ball,
that's
the
number
60.
and
then
you,
when
you
decode
this
base64,
you
actually
see.
Oh,
it's
an
array
with
some
text
in
it
and
and
the
number
42.
I
I
And
one
comment
was
we
actually
need
abnf
for
the
contents
of
of
that
field.
The
abn
f
is
in
in
a
different
draft
and
we
need
to
to
understand
how
we
actually
handle
these
drafts.
So
we
can,
of
course,
just
just
copy
the
content
from
that
other
draft
into
this
draft,
so
we
don't
have
to
reference
it,
but
that
would
of
course,
yeah
kind
of
defeat
the
point
of
the
other
draft,
or
we
could
adopt
that
other
draft
and
and
put
it
on
on
the
same
track.
I
A
A
I
I
Let
me
show
the
other
open
next
slide,
so
issue
number
one:
what
does
it
mean
to
have
a
ct
without
a
binary
value
in
the
record
now
this
can
actually
happen
when
you
have
a
default
value
for
city
obesity,
in
effect,
so
it's
probably
the
best
thing
to
to
simply
make
this
allowable,
but
without
consequences.
So
that's
the
the
change
that
is
being
proposed
and
I'm
I'm
pretty
sure
it's
innocuous,
but
of
course
we
all
should
be
thinking
about
that
before
we
go
ahead
with
it.
I
So
that's
pretty
much
the
the
technical
content
here
and
so
procedurally
next
step
once
these
two
items,
the
next
slide
excuse
me
slide
is
called
next
steps.
Once
we
we
have
processed
these
comments,
we
of
course
can
recheck
whether
we
covered
everything
that
was
in
the
reviews
and
then,
since
we
didn't
really
do
a
lot
of
technical
changes.
We
probably
can
submit
to
isg
at
this
point,
but
we
still
have
to
decide
on
on
how
to
handle
the
the
abnf
issue.
K
I
I
I
I
I
I
A
G
I
G
G
Fair
enough
and
I'm
okay,
also
okay
with
that,
assuming
that
we
don't
get
that
other
draft
doesn't
get
stuck
in
the
process
for
very
long
time,
because
the
city
is
essentially
ready
to
publish,
but
I
guess
we
can.
We
can
I
mean,
do
the
whole
hallway.
With
this
I
mean
going
forward,
I
keep
having
the
normative
reference
and
just
make
sure
that
the
media
content
time
format
you
know,
goes
smoothly.
I
M
I
I
So
this
is
essentially
a
reaction
to
the
problem
that
we
have
been
having
in
about
a
dozen
core
documents
that
we
we
never
quite
properly
distinguished
media
types
from
content
types
and
that
we
used
content
format
where
we
actually
meant
content
type
and
vice
versa.
And
so
this
is
essentially
a
housekeeping
document
that
that
will
be
a
little
bit
like
like
a
2119
for
the
for
this
group.
A
Okay,
so
maybe
just
to
clarify
a
bit
so
on
borman,
core
media
content
type
that
one
will
be
shepherd
by
alexey
or
at
least
he's
volunteering
on
the
chat
right
and
carson
on
this
document,
then,
would
you
expect
any
major
changes
for
the
next
version?
So
can
we
let
people
know
that
they
should
start
doing
the
reviews
as
as
soon
as
possible,.
I
A
I
A
I
O
M
L
M
A
Q
Q
Okay,
so
the
updates
in
o2,
as
opposed
to
one,
we're
just
basically
saying
that
the
the
options
that
you
either
have
to
support
both
or
neither
you
can't
just
support
one
of
the
two
of
them.
We
talked
about
or
updated
how
tokens
can
be
handled
to
reduce
the
number
to
be
tagged
to
be
tracked,
because
we
can
be
sending
out
a
whole
load
of
requests
at
once
and
they
need
individual
tokens
some
clarifications
about
when
multiple
instances
have
been
used
and
we
removed
the
restriction
on
the
231
response
code.
Q
How
we
handle
packets
that
we
can't
send
responses
back
to,
because
there's
too
many,
let's
say,
options
some
sort
of
christmas
tree
packet
coming
in
next
slide.
Please
updated
the
the
definition
of
how
we
are
holding
the
data
in
terms
of
the
response
to
say,
we
need
these
specific
blocks
to
be
re-transmitted,
making
this
notes
about
the
fact
that
every
max
payloads,
when
we
send
out
up
to
10
packets,
then
congestion
control
kicks
in
and
there's
an
act.
Q
Timeout
delay
making
the
recommendation
that
it's
not
used
in
a
no
sex
security
mode
because
of
potential
security
issues.
If
we
don't
do
that-
and
there
was
a
comment
in
there
about
repeat
request-
we've
clarified
that
by
updating
how
we're
using
the
m
bit
in
the
blocks-
and
we
went
for
changing
the
name
of
the
options
to
cue
block,
1
and
q
block
2-
which
we
are
subject
with
a
couple
of
slides.
Hence
next
slide,
please,
okay,
so
for
the
option
naming
originally,
it
was
block
three
block.
Q
Four
that
was
said
that
there
was
confusion
because
there's
block
one
and
block
two.
We
set
up
a
doodle
for
the
naming
and
out
of
that,
the
the
people
who
responded
we
went
for
q
block.
Now
there
has
been
some
comments
about.
Q
block
may
not
be
acceptable
in
certain
parts
of
the
world.
We're
just
looking
for.
Is
it's
good
to
continue
with
q
block,
or
should
we
be
using
some
other
block
here
and
either
we
take
a
decision
here
or
we
go
back
and
revisit
the
poll?
Q
A
B
Q
Yes,
essentially,
is
that
we
have
here
the
ability
to
be
able
to
send
a
stream
of
packets
like
in
a
kind
of
a
non-environment
where
we
can
have
unidirectional
transmission
of
blocks,
and
there
is
block
recovery
in
the
protocol
etc,
and
it
just
is
the
name
for
the
block
that
supports
this.
We
can
send
multiple
blocks
without
having
to
wait
for
acknowledge,
because
the
standard
block
one
block
two
has
a
request
response
request
response,
synchronization
step
was
with
this
quick
block.
Q
B
A
Q
Yep
next
slide,
then,
please,
thank
you
very
much
everyone,
okay,
so
we
have
in
here
congestion
control,
which
is
absolutely
correct,
especially
as
we're
talking
about
primarily
udp
here
and
network
flooding,
all
the
rest
of
it.
So
when
we
have
a
large
body
of
data
to
send
it
gets
parceled
down
into
the
now
cue
blocks
and
we're
either
pushing
it
up
to
the
server
or
the
server
sending
response
back
to
us,
but
in
there
we
have
the
concept
of
max
payloads
that
in
every
10
packets
we
have
an
act.
Q
Timeout
delayed
delay
just
to
make
sure
that
we're
just
not
flooding
the
network.
By
using
con,
we
can
see
that
there's
an
acknowledgement
and,
in
particular
the
max
payload
packet.
If
a
con
comes
back,
we
know
that
the
network
is
still
functioning
and
we
can
then
carry
on
transmitting,
but
in
the
environments
that
specifically,
these
blocks
came
up
for
which
is
in
some
ddos
attack
environments.
Where
there's
network
losses,
we
can't
always
use
a
con
because
we
then
lose
that
packet.
Q
So
in
the
case
of
non,
which
is
the
preferred
how
we
operate
in
the
particular
lossy
environment,
we
would
be
waiting
for
timeouts,
and
so
the
question
really
came
up
is
how
can
we
reduce
these
turnaround
times
if
the
network
and
the
environment
are
all
fine
and
can
handle
the
particular
sort
of
packet
load,
so
the
concept
of
signaling,
something
in
the
max
payload
packet
to
say
I
want
a
response
of
some
sort.
If
the
response
doesn't
come
back
through
lossy
networks,
we
still
wait
the
act
time
out.
It's
not
the
end
of
the
world.
Q
It
was
suggested
last
time
around
that
we
can
use
the
no
response
option,
which
is
an
excellent
idea,
but
it
only
works
for
pushing
data
to
the
server.
The
no
response
option
can't
be
used
for
when
the
server
wants
to
send
back
some
sort
of
subscription
observe
response
or
whatever
it
may
be.
That
no
response
is
not
a
standards
track.
I
don't
know
if
that's
an
issue,
but
really
the
question
is
also.
Q
How
can
we
handle
block
two
and
if
we
are
using
for
whatever
we
do
for
block
q
block
two,
we
could
we
need
to
think
about
doing
it
for
q
block
one
as
well.
Does
it
make
sense,
for
both
last
time
around
proposed
that
we
added
in
an
additional
bit
into
the
block
option,
the
r
bit
and,
if
set
just
means
trigger
some
sort
of
response
or
trigger
the
next
get
request?
Q
It
came
back
with
how
about
the
no
response
option,
but
we
looked
into
that.
We
found
it
unfortunately
only
works
for
qblock
one.
So
is
it
worth
going
forward
with
something
like
this
response
bit
or
does
the
working
group
think
well?
Does
it
really
matter
if
we
just
have
this
act
time
out
in
two
seconds
pause
period
periodically,
so
that's
really
where
the
question
here
is
any
feedback.
E
On
the
on
the
topic
of
is,
is
that
act
timeout?
Okay?
I
think
you
are
the
best
to
answer
that.
So
do
you
expect
to
run
into
this?
That
often
at
all
I
mean
given
that
you
10
10
payloads
are
already
quite
a
bit
issue
problem
for
your
application,
because
if
it
is,
then
it
needs
to
be
addressed.
If
not,
you
know
you
are
the
driving.
You
have
the
driving
use
case.
Q
Okay,
I'm
enjoying
this
okay.
So
what
we're
talking
about
here
is
passing
telemetry
information
about
what's
happening
with
ongoing
attacks
between
the
client
and
the
server,
and
if
there
is
a
fairly
aggressive
christmas,
e3
type
attack,
that's
taking
place,
which
is
taking
place
with
multiple
vectors
and
multiple
things
going
on.
At
the
same
time,
then,
it's
very
easy
to
overflow,
the
ten
packets,
okay.
Q
But
if
we
can't
come
forward,
it's
there's
a
two
second
delay
in
the
a
two
second
delay
is
not
critical
in
terms
of
ddos
attacks,
but
it's
nice
to
be
able
to
for
the
peers
to
be
able
to
exchange
information
so
that
people
are
trying
to
mitigate
the
attack
can
be
more
effective
more
quickly
or,
if
they're,
using
ai
to
kind
of
control.
The
attacks.
E
Q
Sure,
okay,
but
there's
no
response,
it's
it's!
It's!
It's
a
third
party
ie,
not
core
standard.
It's
not
a
status
track,
so
modifying
that
would
be
difficult
and
also
the
fact
that
it
says
response
in
its
name
is
not
appropriate.
It
could
be
that
we
come
up
with
another
option
to
handle
this,
but
I'm
just
not.
I
just
don't
want
to
spawn
off
options
for
the
sake
of
options.
A
Q
Okay,
so
there
is
some
telemetry
stuff
that
is
passed
over
rescoff,
which
basically
is
vendor
mapping.
So
these
attack
ids
mean
this
type
stuff,
but
in
terms
of
the
actual
telemetry
signaling
that
would
be
done
at
the
signal
channel.
Because
again,
we
are
challenged
by
we're
working
in
lossy
networks.
Q
A
Q
B
Q
Q
A
Okay,
so
usually
for
the
step
of
working
on
glass
call,
we
get
a
few
more
reviews.
Normally,
I
was
wondering,
maybe
if
some
of
those
who
have
been
active
on
on
this
work,
but
not
not
the
authors
like,
for
instance,
christian
or
or
others
would
like
to
volunteer
to
do
a
last
review
or
if
we
would
like
to
do
the
review
during
the
working
class
call
as
well.
I
mean
that's
another
option.
A
Okay,
christian
is
nodding
very
good.
Thank
you
christian.
I
did
ask
two
questions,
though.
So
what
are
you
knowing
for
the
review?
I
I
know
you're
gonna
do
a
review,
but
I
guess
to
you:
it
doesn't
matter
whether
it's
during
the
working
group
last
call
or
or
before
right,
exactly
all
right,
very
good.
Any
anybody
else
would
like
to
volunteer
a
review.
A
Q
C
Q
C
Q
C
Q
A
A
A
P
R
L
Thank
you.
Okay.
Well,
hello,
everybody
good
to
be
back
for
core!
I'm
sorry
that
I've
been
a
bit
silent
lately,
it's
just
been
work,
but
this
is
a.
This
is
a
quick
update
here
about
what's
happening
with
dynalink,
which
they
said
version
11
right
now.
Can
we
please
move
to
the
next
slide
or
yeah,
so
I'm
just
going
to
take
a
bit
of
time
to
to
solicit
some
feedback
about
some
developments
that
are
going
on
in
in
dynlink.
L
My
screen,
just
flashed,
so
is
everything.
Okay,
all
good,
all
good
good,
so
dyn
link
is
currently
at
version
11..
We
are
close
to
releasing
version
12.
constantly.
As
always.
Whenever
there
is
feedback
received,
then
we
try
to
incorporate
that,
and
especially
any
kind
of
corrections
and
clarifications.
L
So
the
slide
side
I'm
describing
right
now
is
basically
what's
in
the
editor's
copyright
or
what
is
the
editor's
copy
at
the
moment
and
and
also
about
the
the
new
proposals
which
are
pretty
much
exclusively
coming
from
from
oma.
So
I
thought
I'll
brief
you
about
what's
happening
there
and
then
get
your
feedback
there
as
well.
L
L
Some
recommendations
on
how
to
proceed
forward,
but
I
think
we
are.
We
have
some
consensus
that
that
will
include
these
two
attributes,
which
are
also
used
in
the
live
m2m
specifications
and
ep
min
is,
is
an
evaluation
period
that
indicates
the
minimum
time
and
that's
that's
separate
from
pmin
and
epmax
is
the
maximum
evaluation
period
between
between
the
two
evaluation
between
the
two
sampling
periods
that
the
server
may
read
and
and
then
notify
the
client
so
ep
and
epmax
are
currently
in
the
in
the
editor's
draft.
L
This
this
particular
slide
mentions
an
interesting
scenario
in
which
we
should
allow
p
min
to
be
equal
to
p
max
in
in
certain
certain
use
cases.
So
the
current
wording
in
dynlink
states
that
the
maximum
period
or
pmax
must
be
greater
than
zero
and
must
be
greater
than
p
min.
If
it's
present,
if
pi
is
present,
the
the
logic
behind
that
is
that
p
min
basically
defines
the
minimum
time
between
two
consecutive
notifications,
even
if
the
if
the
resource
step
has
changed.
L
No,
no,
that's
that's
nothing
about
synchronization
yeah
at
all.
So
no,
but
that's!
The
suggestion
from
the
oma
is
that
they
actually
have
a
use
case
where,
where
they
they
have
an
implementer
who
who
is
looking
towards
sending
exactly
one
notification
per
and
second,
so
what
they
were
wondering
is.
If
there
is
any,
then
you
need
to
have
this.
This
strong
constraint
that
p
max
must
always
be
greater
than
p
min
or
instead
have
bmx
equal
to
pmin.
L
If
the
client
wants
notifications
to
be
sent
every
every
n
seconds.
So
if,
if
we,
if
we
go
with
that,
then
the
text
has
to
change
so
that
the
p
max
must
be
greater
than
zero
and
must
be
greater
or
equal
to
p
min,
if
the
mean
is
present.
So
I
just
like
to
get
some
feedback
on
on
this
new
proposal
from
anybody.
L
L
Comment,
this
dave
had
actually
sent
this
on
the
mailing
list
in
core,
but
but
there
were
no
no
responses
there
so
and
then
he
raised
the
github
issue,
so
I
wanted
to
just
ensure
that
this
is.
This
is
not
something
that
that
goes
unnoticed
and-
and
I
thought
all
the
race
is
not
up
now
and
then,
as
usual.
L
L
Okay,
thank
you
alexi
all
right,
that's
good!
Then.
The
next,
the
next
three
slides
will
we'll
actually
be
talking
about
new
attributes.
If
you
move
to
the
next
slide,
please-
and
these
are
all
by
the
way,
attributes
that
are
found
that
are
found
in
the
the
labyrinth
or
specs,
and
I
think
I
think,
I'm
not
sure
if
they're
already
there,
since
I
I
don't-
have
the
visibility
to
their
specifications,
they're
either
they're
in
the
current
specifications
or
they
are
being
incorporated
in
the
new
one
to
1.2.
A
A
R
O
O
K
L
K
L
E
Just
just
like
just
answers
just
from
looking
at
it
sounds
a
bit
tricky
to
get
this
guaranteed
through
a
proxy,
because
if
it's
only
if
only
the
rising
edge
values
are
sent,
then
the
proxy
might
see.
This
is
a
repetition
unless
there
is,
in
addition,
some
some
p
max
value
that
ensures
that
the
value
is
forwarded
anyway,
which
would
result
in
a
in
a
max
h.
That
means
that
the
proxy
needs
to
send
it.
R
Yeah,
I
I
I
don't
know
if
participants
saw
that
david
just
posted
the
link
to
the
chat
video.
I
actually
wasn't
aware
that
staff
had
uploaded
this,
so
this
is
the
version
I
want
to
do
of
the
specification,
which
is
brand
new,
something
we
had
worked
on
over
a
long
period
of
time
and
contains
a
couple
of
new
interesting
features:
multi-transport
gateway,
support,
etc.
R
R
Information
about
this,
given
that
it
hasn't
been
available
in
the
didn't
link
draft.
But
the
intention
is
to
have
sort
of
the
whole
bundle
that
didn't
link
document
with
these
attributes
to
be
available
as
a
idf
rc
and
then
to
make
a
reference
instead
of
including
the
text
in
in
the
library
and
term
specification
itself,
because
we
have
been
extensively
using
and
referencing.
The
work
from
this
group.
L
Okay
and-
and
also,
I
think
I
think,
dave-
is
davis
here.
I'm
sorry
dave
that
I
didn't
see
that
you
were.
You
were
in
the
in
the
call
when
I
checked
so
we
just
covered
one
of
the
github
issues
that
you
just
raised
regarding
the
pmin
pmax,
and
if
you
have
any
comments
on
that,
then
please
feel
free
to
mention
it.
L
I'm
trying
to
monitor
the
chat
as
well
at
save
time.
So,
okay,
thank
you
all
right.
So
then,
let's
go
to
the
next
attribute,
which
is
called
the
con,
and
this
is
taken,
and
I
believe
that
ellen,
when
he
put
these
issues
in
in
github,
he
basically
took
the
the
text
from
the
the
course
back
itself.
So
so
this
the
terminology
is
very
is
very
specific
to
libra
m2m,
but
obviously
that
needs
to
be
modified
in
order
to
fit
into
dynamic.
L
G
O
Yes,
so
yes,
in
the
right
recent
specification,
there
is
a
separation
between
the
lightweight
and
twin
protocol
and
the
under
transports,
which
is
which
can
be
co-op
or
new
things
now
so.
Hence
the
that's
strange
are
working,
but
basically
is
this:
when
you
are
using
co-op
over
udp
to
observe
a
resource,
this
attribute
will
just
tell
you
to
send
the
notification
as
confirmable
message,
confirmable
message:
instead
of
co-op
non-confirmable
response.
E
All
right,
then,
we
have
christian
sorry
to
say,
come
up
with
the
same
thing
all
over
again.
This
is
something
that
works
for
the
origins
for
the
origin
server,
but
it
doesn't
necessarily
work
for
proxies.
So
I
think
we
now
have
the
separation
of
things
that
configure
the
server
and
things
that
are
actually
kind
of
relating
that
work
in
the
rest
architecture,
and
if
this
goes
into
this
configuring,
the
server
bin,
so
so
be
it.
E
But
I
don't
think
that
this
is
a
general
thing
that
we
should
advertise
for
for
for
co-op,
because
this
is
this
works
as
long
as
you
don't
have
proxies
in
there
and
yes,
that
might
be
a
situation
in
which
some
architectures
are.
But
this
is
not
the
generic
case.
So
if
it's
in
that
bin
meh,
but
it
should
be
noted
there.
E
E
So
the
proxy
cannot
rely.
You
cannot
rely
on
all
hops
in
the
in
the
proxy
chain,
ascending
this
value
as
con,
and
even
if
you
do,
if,
after
this
con
another
non
comes
around,
maybe
the
other
proxy
doesn't
even
see
that
something
was
sent
on
this
con.
So
you
can
tell
the
server
that
it's
that
you
want
the
server
to
do
something
like
this,
but
you
can't
expect
this
to
extend
over
the
whole
chain.
L
A
R
Also
well,
this
is
honest
again
yeah
and
in
the
lightweight
mdm
architecture,
there
is
no
there's
no
proxy
per
se,
so
the
issue
doesn't
occur
but
yeah.
It's
definitely
something
worthwhile
to
look
into
on
how
this
relates
to
some
of
the
others
and
what
could
be
done
to
make
it
work
over
through
proxy.
If
someone
wants
to
have
that
feature.
E
The
thing
is,
if
you
want
to
specify
it
in
core,
I
think
it
has
to
work
with
the
generic
rest
architecture
if
it
only
needs
to
work
for
the
live
with
m2m
case,
where
there
are
no
proxies,
then
this
is
something
that
can
be
extended
on
the
list
of
attributes.
We
define
here
for
this
particular
application.
A
A
L
I
have
just
one
one
other
attribute
that
was
put
into
the
in
the
list
and
I
and
I
don't
believe
that
we
need
to
discuss
that
thoroughly
since
we
can
schedule
some
time
during
intermin
interim.
So
so
then,
the
other,
the
the
last
attribute
that
was
proposed
by
ellen,
was
hq
max,
which
was
for
maximum
historical
queue
and,
and
it's
a
very
worthy
little
passage
that
I've
I've
written
here.
A
L
A
B
A
A
A
S
Hopefully,
okay,
I
I
try
to
do
this
very
quickly,
so
you
can
keep
here
scare
you.
So
this
is
a
quick
status
update
on
on
passwords
craft
next,
please
so
there
hasn't
been
a
sparrow's
update
for
a
while.
So
a
very
quick
recap
on
what's
this
all
about
so
far,
is
an
alternative
algorithm
for
co-op
to
handle
re-transmission,
timeout
and
consciousness
control.
S
So
it's
optional
mechanism,
just
like
the
the
coco
and
I'm
not
going
to
go,
do
the
details,
how
it
works,
but
just
saying
that
it's
pretty
similar
to
the
tcp
timer
mechanism,
which
provides
the
two-state
exponential,
back-off
logic.
But
we
add
there
a
an
additional
state
and
that
allows
the
fossil
to
to
have
one
quick
retransmission
to
to
address
random
wireless
losses
so
recovering
quickly
in
those
cases,
but
at
the
same
time
it
kind
of
does
the
tool
back
off
to
take
care
of
potential
congestion.
S
So
zero
zero
version
was
published
in
in
march
after
the
working
group
adoption
and
there
we
addressed
the
feedback
from
christopher.
That
was
recording
the
the
retransition
count
option.
So
we
clarified
the
the
limitations
in
in
the
use
of
the
the
option,
so
so
basically
saying
that
here,
for
example,
if
there
is
a
proxy
in
use
which
is
sending
empty
empty
acknowledgements,
then
then
the
option
cannot.
H
S
S
So
now
we
just
simply
explicitly
say
that
that
we
increment
the
value
by
one
on
its
retransmission
and
just
a
few
additional
editorial
changes.
So
that's
that's
basically
also,
as
we
can
see
there
is.
There
has
not
been
much
modification
for
for
over
one
year
now,
so
that
takes
us
to
the
next
steps
in
the
next
slide.
Please.
S
So
what
obviously
we
we
would
like
to
have,
and
and
and
what
is
needed,
is
more
review.
So
please
read
the
craft
and
and
provide
us
feedback,
and-
and
we
did
also
because
this
is
about
the
construction
control.
So
we
need
some
feedback
from
the
reviews
from
the
transport
area
as
well
and-
and
I
believe.
S
T
Yeah,
okay,
so
I
was
saying
first
of
all,
I
believe
this
is
important
work
and
also
interesting
and
interesting
mechanism,
and
one
comment
would
be
about
the
amount
of
evaluation
work
related
with
this
document.
So
when
we
did
the
work
on
cocoa,
we
were
warned
that
we
would
need
to
to
make
it
sure
that
the
document
well,
the
mechanism
would
be
safe
and
we
did
lots
of
evaluation
and
well.
It
was
only
in
the
end
that
we
found
well.
You
found
some
issues
in
some
scenarios.
S
So,
okay,
we
we
have
done
the
from
our
party,
the
evaluation
and-
and
it
would
be
very,
very
good
if
we
have
some
additional
evaluation
by
by
some
other
thoughts.
I
haven't
checked
there.
There
are
a
number
of
papers
that
have
been
very
recently
or
quite
recently
published
if
someone
actually
already
has
done
so
so
I
had
something
that
we
need
to
check
if
there
is
already
is
additional
evaluation
but
but
any
any
any
evaluation.
This
is
very
welcome.
T
T
S
S
A
A
A
A
P
E
E
So
this
this
would
be
yeah
our
next
slide,
please,
the
the
hard
question
here
is,
of
course,
why
would
we
want
to
do
this
because
we
already
have
a
perfectly
good
way
of
using
co-op
over
bluetooth?
That
is
ipsp
and
the
reason
I
propose
this
is
that
we
have
the
same
situation
that
we
have
with
web
browser
applications
also
with
some
smartphones.
E
So
while
in
theory
the
device
that
would
want
to
participate
in
the
internet
of
things
has
the
technical
capabilities
to
in
websockets
case
open
a
tcp
connection,
open
a
udp
connection,
and
in
this
and
the
bluetooth
case
run
ipsp,
the
application
is
typically
not
in
a
position
to
do
the
full
to
to
actually
use
it.
So,
while
ipsp
has
been
implemented
in
linux,
it's
not
practically
available
on
android
and
same
seems
to
be
true
for
for
ios
based
devices.
E
So
you
can
you
can
if
you,
you
have
a
smartphone
and
you
have
a
device
and
you
want.
Basically,
you
are
in
control
of
both
of
them,
but
you
can't
establish
a
connection
with
co-op
yet
so
this
is
proposing
to
tunnel
co-op
over
get
because
get
is
available
on
everything
on
on
for
phone
applications
and
at
least
for
at
least
for
chrome,
even
even
from
the
browser
and
like
web
sockets.
E
There
is
a
potential
additional
use
case
in
that
this
could
be
combined
with
chick
to
even
make
things
available
that
don't
speak
coordinatively
without
real
application,
specific
software,
but
more
with
application.
Specific
headers,
but-
and
I
don't
use
out
of
out
of
font
characters
lightly.
There
is
a
large
question
mark
behind
this
for
a
very
good
reason,
and
this
is
just
something
to
be
that
can
be
explored
while,
while
going
along
with
this
next
slide,
please
so.
E
The
mechanism
that
is
currently
proposed
is
to
have
a
bluetooth
characteristic
and
that
that
the
I'll
say
phone
to
just
identify
the
rules,
because
I'm
not
too
good
with
the
full
bluetooth
terminology
uses
the
bluetooth,
write
method
to
write
the
method,
the
any
options
and
the
payload
into
that
characteristic
and
later
on.
Read
it
back
out
where
there
is
a
notification
mechanism
and
where
there
is
a
way
like
a
notification
mechanism
that
allows
asynchronous
processing
here
and
also
there
is
a
mechanism
to
do
those
rights
in
a
in
a
reliable
way.
E
So
we
don't
have
to
import
the
whole
message
id
and
message
type
mechanism
from
co-op
over
over
udp,
and
we-
and
at
least
that's
something
that
I'm
I'm
I'm
playing
around
with
here.
We
might
not
even
need
to
do
tokens
because
there
is
already
a
multiplexing
mechanism
available
for
those
descriptors.
So
why
not
use
that
in
practice?
It's
showing
that
one
limit
here
is
the
the
mtu
which
appears
to
be
for
most
modern
devices,
512
bytes,
which
means
that
we
can
transport
the
full
kind
of
a
reasonable
co-op
message
in
there.
E
We
just
have
to
fragment
on
the
co-op
level,
but
we
have
the
mechanisms
for
that,
so
that
shouldn't
be
too
much
of
an
issue,
but
this
still
needs
further
experimentation
on
what
practical
devices
really
offer,
because
if
the
specification
wise,
this
could
go
down
to
something
like
32
byte
and
we
can't
really
work
in
in
that
area
anymore,
with
even
with
block
wires
fragmentation
without
creating
huge
overhead.
So
if
that
is
really
relevant,
then
some
some
additional
fragmentation
mechanism
might
be
necessary,
but
right
now
I
hope
we
can
avoid
that
next
slide.
E
Please
the
hardest
part
about
this,
I
think,
is
not
how
to
align
it
technically,
but
how
to
make
it
work
with
the
with
the
uri
space
that
we
that
we
all
use.
So
what
co-op
over
web
sockets
and
tcp
et
cetera
are
doing
they're
introducing
this
additional
scheme,
which
then
could
encode
the
bluetooth
address
or,
as
in
the
web
browser
case,
just
some
identifier,
which
really
behaves
and
that's
the
third
line
here,
behaves
like
an
interface
identifier.
E
Before
I
get
to
the
next
steps.
There's
a
next
slide,
please
just
kind
of
as
a
brief
demo
on
how
I
how
this
looks
like
in
practice.
So
even
if
you're
going
from,
if
you're
accessing,
if
you're
running
from
a
smartphone,
you
can
go
to
web
website,
you
can
access
that
bluetooth
device
by
pushing
a
button,
then
the
browser
asks
you.
E
Basically,
the
browser
looks
through
what
is
available
locally
allows
you
to
pair
with
one
of
those
and
which,
in
many
cases,
doesn't
involve
any
additional
steps,
and
then
you
can
run
code
over
that
and
and
use
any
addition.
Any
security
context,
for
example
like
oscar
that
you
establish
in
that
you
establish.
However,
you
establish
the
next
slide
please
and
once
you've
clicked
there.
You
see
the
co-op
exchange
playing
out
here.
So
this
is
a
very
minimal
demo.
I
have
one
implementation
for
each
site
out
there
or
two.
E
The
other
party
has
implemented
this
as
well,
so
this
is.
This
is
working
enough
to
to
to
run,
but
of
course,
it's
still
very
early
next
slide.
Please
so
there's
a
lot
of
implementation,
experiments
together
here
and
I'm
actively
doing
this
in
parallel
with
advancing
the
draft
further
to
see
whether
there
needs
to
be
additional
changes
and
also
to
expand
functionality
right
now.
E
This
can't
even
send
requests
from
the
device
to
the
smartphone,
so
this
is
clearly
not
a
full
co-op
transport
yet,
but
yeah
the
right
now
I'd
like
to
so
my
my
proposal
is
to
keep
this
as
an
experimental
document
that
just
describes
that
there
are
people
who
are
running
co-op
over
cat,
and
this
is
how
they
do
it,
but
yeah.
Basically,
I'd
like
to
hear
from
from
the
working
group
whether
you
want
to
have
some
work
about
this
here
or
whether
you
have
any
other
good
input
that
I
could
process
into
this.
E
The
the
thing
is
the
way
to
do
it.
There
is
already
good,
but
applications
often
find
themselves
in
a
situation
where
they
can't
do
it
right,
and
then
they
have
to
do
it
wrong,
which
is
by
hooking
into
a
mechanism
that
is
not
designed
for
this
kind
of
thing,
but
that
happens
to
be
the
only
thing
that
operating
systems
expose.
E
So
this
is
a
workaround
and
sure
this
could
be
made
into
a
workaround
that
also
encompasses
six
low,
which
is
something
that
was
proposed
by
in
a
similar
way
by
developers
at
fitbit
who
published
their.
I
think
they
call
it
golden
gate
proposal,
which
is
basically
udp
over
cat,
which
is
just
or
ip
overcat,
even
which
is
kind
of
having
the
same
drawbacks,
but
just
put
pulling
in
more
layers.
E
So,
yes,
that
would
be
an
alternative,
but
I
think
that,
given
that
we
are
already
kind
of
stacking
up
workarounds
here,
using
going
for
co-op
right
away,
is
the
easier
and
more
convenient
approach,
especially
given
that
this
will
never
end
up
visible
to
an
operating
system.
So
you
can't
use
the
operating
systems
network
stack,
which
you
usually
would
want
to
use
anyway
and
would
then
need
to
ship
your
additional
ip
stack.
C
Michael
go
ahead,
please
so
I
browsed
your
document
because
we
I
mentioned
the
interest
at
the
beginning
of
the
session,
and
you
mentioned
you're
talking
about
it
and
I
go
oh
okay.
So,
somewhere
in
the
document
it
says
coat,
plus
gap,
g-a-t-t
and
and
then
other
places.
It
says
bluetooth
and
I
looked
at
the
w3c
document
a
little
bit.
It's
long,
it's
not
like
so
long,
but
what
I
didn't
discover
yet
is
how
or
if
the
bluetooth
connection
gets,
authenticated
or.
E
C
C
C
E
Yeah
yeah
theory.
Yes,
I
mean
there
there
is.
There
is
the
possibility
that
you
do
use
the
additional
modes,
which
would
then
probably
fall
back
to
nfc
for
the
for
the
proximity
based
business,
authentic,
bluetooth,
initialization,
so
you
kind
of
would
would
go
through
another
step
that
might
that
might
be
a
way
to
to
avoid
the
the
bluetooth
range
here,
but
yeah
either
way
should
work.
C
E
H
E
C
A
E
With
mozilla
and
yeah,
I
think
I
I
had
it
on
the
slides,
but
I
didn't
talk
about
it.
So,
yes,
first
chrome.
Yes,
I
tested
it
on
chrome,
both
of
chromium
both
on
from
linux
and
from
android
safari.
I
don't
have
access
to,
but
the
thing
is
with
mozilla
they
evaluated
the.
They
found
a
position
for
co-op
over
sorry
for
browser
access
to
get
and
their
position
is
that
it's
not
secure,
which
is
understandable.
E
So
I
I
won't
go
into
the
full
background,
but
the
the
thing
is,
the
bluetooth
device
doesn't
specifically
ask
to
be
contacted
by
a
browser.
So
so
they
don't
want
to
to
open
us
up
into
another
cross-origin
situation.
Now,
even
with
different
protocols,
there
is
a
suggestion
of
how
to
do
it
better
from
mozilla,
especially
ecker
and
martin
thompson,
whom
I
want
to
get
back
on
this.
E
Basically
after
we've
talked
about
this
here,
that
would
probably
wind
up
with
something
like
webrtc
data
channels,
over
b
over
gut,
and
then
we
could
hook
into
that.
So
if,
if
that
becomes
a
thing,
that
would
be
great
because
it
would
mean
that
it's
accessible
from
mozilla
devices
as
well,
but
this
would
probably
look
a
lot
different,
at
least
on
the
wire
and
we'll
have
to
see
whether
this
can
be
something
that
is,
that
supersedes
what
we
do,
what
I'm
doing
here
right
now
or
that
would
be
in
like
an
augmentation.
A
Personally,
I
think
I
think,
by
the
way,
that
this
is
great,
that
we
are
at
least
taking
a
position
on
this,
because
I
have
read
so
many
theses
and
papers
and
work,
but
don't
buy
others
on
on
this
topic
and
and
it's
nice
to
have
somewhere
where
we
can
point
them
to
so
an
experimental
draft
would
be
perfect.
I
think
so.
J
J
J
What
they
are
based
on
is
that
you
choose
the
probability
and
the
length
of
your
messages,
typically
maximum
length,
and
then
you
get
limits
for
the
number
of
packets
to
encrypt
and
the
number
of
failed
decryptions,
and
it's
worth
noticing
that
these
equations
are.
These
are
not
equations,
there
are
inequalities.
So,
basically,
if
you
choose
numbers
for
v
and
q,
you
know
that
your
probability
for
a
four
jury
attack
is
lower
than
some
value,
but
it
might
be
much
lower
or
it
might
might
be
close
to
the
bound.
We
don't
simply
don't
know.
J
They
are
at
least
a
lot
stricter
than
any
previous
security
protocol,
and
I
think
that's
good
for
general
use
and
re-keying
is
easy.
So
that's
not
the
problem
for
general
non-constrained
use
of
this
protocol.
At
least
you
can
see
below
here
that
the
limits
are
around
20
package
and
for
ccm8
in
dtls.
It
must
not
be
used
without
additional
safeguards.
J
In
tls,
it's
okay
to
use
because
tls
sets
v
to
1,
so
it's
not
the
problem
to
use
ccm8
there,
and
I
think
this
is
very
good
work
from
cf
audi,
but
in
general
I
don't
think
this
is
probably.
This
is
not
the
biggest
security
problem
that
implementation
have.
I
have
never
heard
of
a
practical
problem
with
a
64-bit
tag.
J
I
think
there's
I
think,
distinguishing
attacks
are
very
theoretical.
They
it's
hard
to
say
if
they
have
any
practical
implication
at
all.
Forgeries
are
very,
very
practical.
Somebody
gets
a
forged
message
to
you.
I
think
there's
a
lot
of
things
that
can
be
discussed
for
a
iut
setting
yeah
the
probability
two
to
the
minus
57
for
tls,
dtls
and
quick
was
its
arbitrary
issues
it
and
I
think
we
can
definitely
accept
the
slightly
higher
for
your
probability
for
constrained
iot.
J
Any
effects
on
the
system
should
be
denial
of
service
effect
should
be
com
compared
with
other
denalo
service
attacks
on
the
system.
Also,
messages
is
much
lower,
but
that
may
or
may
not
matter
actually,
and
then
there
are
some
other
solutions
that
you
you
might
not.
You
might
or
might
not
look
at
absolute
length
and
you
might
not
close
the
connection.
J
You
can
still
send,
for
example,
error
messages,
saying
that
please
rekey
next
slide
so
specific
for
os
score
au
score
has
the
number
package
you
can
encrypt
is
dependent
on
the
algorithm,
but
it's
always
lower
than
two
to
power.
40
and
currently,
I
don't
think
any
of
the
algorithms
have
lower
limits
specified.
J
J
J
After
this
ln
p
has
been
used
and
there's
some
slight
trade-off
between
the
limits
q
and
we
there's
been
some
discussion
in
lake
already
and
tls
dtls
quick
have
discussed
this
in
their
working
groups.
I
assume
tls
working
group
will
discuss
this
more
for
ctls
there's
a
discussion
for
lake
questions.
J
If
there
are
any
other
protocols
use
of
ccm
in
iut
in
itef,
where
this
is
relevant,
more
specific
for
os
score,
we
think
it's
needed
a
new
draft
that
introduce
that
you
need
to
keep
count
of
q
and
v,
how
many
protected
packages
and
failed
failed.
Decryptions
and
q
q
counting
is
needed
on
the
server.
The
client
already
does
this,
then,
when
maximum
values
of
these
have
been
decided
or
yeah,
we?
How
is
that
decided?
Who
decides
and
how
it's
communicated?
J
Then
we
need
to
specify
actions
when
the
limits
are
reached,
which
is
re-keying
could
also
be
sending
error,
messages
to
ricky
and
then
implementation
guide
guidance.
For
example,
when
you
have
a
reboot
similar
things
are
needed
also
for
group
or
score
group
score.
It's
a
little
bit
more
complicated.
J
It
might
be
slightly
worse
for
some
reason
or
slightly
better
than
two
pero
score
for
some
reason.
That's
for
further
study-
and
this
leads
to
thoughts
that
it
we
should
analyze-
maybe
more
lightweight,
symmetric,
key
re-key
mechanism
for
oscar.
It
might
be
it
it's
possible
to
do
something
lighter
than
the
current
question
is:
if
it's
worth
doing
that,
that's
for
further
study
yeah,
I
think
we
can
go
to
christian
slides
or,
if
there's
questions,
comments
on.
E
This
so
what
we
are
seeing
here
is
basically
a
kind
of
a
sketch
of
a
sketch
of
the
numbers
we've
been
getting
in
here
now
and
to
which,
which
should
help
us
determine
the
effect
of
the
the
effect
of
those
limits.
So
just
to
run
you
through
the
axes
on
on
the
axes
going
from
left
to
right.
We
see
the
length
of
messages
on
the
axis
coming
from
from
within.
Within
the
picture,
we
see
how
many
messages
we
can
encrypt
on
on
the
vertical
axis.
E
We
see
how
many
messages
we
may
decrypt
kind
of
how
many,
after
how
many
failures
to
decrypt
the
message
we
need
to
leave,
leave
that
key
re-key
stop
the
connection
whatever
up
until
so
for
me
up
until
start
of
the
week
when
I
heard
of
the
cfrg
document
practically
up
until
we
do
something
about
this,
our
action
space
was
rather
big.
We
could
encode
encrypt
up
to
2
to
the
power
40
messages,
provided
that
key
lets
us.
E
E
The
lines
here
indicate
red
red
is
aes
gtm,
which
has
a
comparatively
long
tag,
and
this
is
on
the
safe
side.
Cha-Cha
is
independent.
The
chatter
numbers
are
independent
of
the
number
of
messages
we
send
at
all,
and
the
blue
and
troops
indicate
the
limits
for
aes,
ccm
and
turkeys
in
say,
ccm8
next
slide.
Please.
E
But
the
re-keying
is
not
so
expensive.
So
if
we
could,
if
we
can
justify
an
altered
limit
of
p,
say
for
the
dashed
version
p
to
the
power
of
minus
2
to
the
power
of
minus
52,
which
is,
admittedly
grabbed
out
of
thin
air.
But
there
needs
to
be
discussion
that
I'm
not
qualified
to
to
contribute
to
on
on
the
particular
value.
E
So
the
hard
cutoffs
here
are,
depending
on
the
on
the
values
2
to
the
power
of
23,
to
2,
to
the
power
of
26,
and
so,
if
we
allow
the
partial
iv
number
to
go
all
the
way
up
there,
then
this
severely
limits
the
number
of
failures
we
can
tolerate.
But
if
we
just
put
it
an
order,
a
binary
order
of
magnitude
below
that
we
are
already
roughly
at
that
plateau
limit.
So
we
don't
have
to
reduce
the
number
of
on
encryptable
messages.
E
A
B
Yes,
ben
was
mostly
mentioning
about.
Perhaps
if
you
only
send
it
once
and
then
close
the
connection,
it
is
close
enough.
So
there
was
really
the
connection
closing
early
in
the
in
john's
presentation
and
otherwise
there's
no
explicit
rational
coming
to
the
bounds
for
tls,
for
what
is
worth
more
kane
has
background
information
from
carsten.
B
A
J
I
Here
we
can
devote
an
entire
interim
to
a
view
from
the
core
world
on
on
the
crypto
world,
because
things
have
changed
since
we
made
the
decisions
some
some
seven
or
eight
years
ago,
what
went
into
seven
two
five
two,
and
maybe
it's
just
a
good
idea
to
to
open
this
up
a
little
bit
more.
Look
at
that
ketchup,
related
things,
look
at
new
modes
and
so
on
and
just
see.
Is
there
anything
that
that
is
getting
ready
for
being
picked
up,
or
at
least
we
should
be
starting
to
do
experiments.
F
You're
on
here
I
have
a
little
comment,
I
think,
while
we
we
should
look
at
what's
coming
next.
We
also
need
to
handle
what
we
have
in
terms
of
hardware,
support
and
existing
devices.
I
think
we
need
to.
We
need
to
run.
We
need
to
run
with
ccm8
for
a
while
and
that's
basically,
what
one
of
these
activities
can
address.
Okay,
you're,
not
disagreeing
with
that
person
great
so
just
like.
Could
you
go
to
the
last
slide
of
john's
presentation?
F
Just
quickly
say
a
few
words,
as
I
said
there
are.
These
are
four
activities
here.
The
first
paragraph
second
paragraph
and
the
next,
the
last
and
last
statements
are
four
different
activities
and
for
the
four
first
activity,
I
wondered
that
I
think
it's
not.
We
need
to
get
beyond
core
there.
What
people
or
what
iot
deployments
are
what
companies
are
working
with
with
iot
and
and
see
the
need
to
use
ccm8,
and
how
do
we
handle
these
new
restrictions
on
ccm?
F
Well,
the
second
paragraph
is
that
that's
a
new
draft
there,
where
there's
already
material
in
this
and
this
presentation
we
could
work
on
the
group-
was
core
people
need
to
look
at
the
that
and
adapt
it
and
for
the
last
one
that's
basically
if
there
is
sufficient
support
and
interest
to
to
work
on
a
on
a
lightweight
secret,
ricky
mechanism.
I
think
that
we
should
do
that,
but
that
sort
of
it's
based
on
interest
from
the
community.
F
A
K
F
I'm
sorry
it
wasn't
you.
Yes,
I
think
I
mean
everyone
that
that
that
I
mean
this
is
industry
consortium.
These
are
different
areas
in
the
idf
that
that
that
needs
to
use
ccm8.
Basically,
that's
that's
a
good
starting
point.
How
do
we
continue
using
ccm8
for
the
time
until
we
have
some
some
alternative
and
so.
K
J
A
Okay,
it
sounds
like
let's
expose
it
now,
because
we're
already
beyond
the
time.
Thank
you
for
the
presentation.
Thank
you
for
the
discussion.
I
guess
this
is
material
for
yet
another
interim,
I
think
yeah.
We
should
maybe
have
it
at
some
point
shortly.
So
thank
you
all
for
attending
course.
Thank
you
for
the
time.
Thank
you
especially
for
those
in
the
us,
because
it's
pretty
late
for
you
and
for
the
rest
of
us
in
europe
have
a
nice
friday
and
those
in
asia.