►
From YouTube: IETF105-LAKE-20190722-1550
Description
LAKE meeting session at IETF105
2019/07/22 1550
https://datatracker.ietf.org/meeting/105/proceedings/
B
C
D
B
C
D
F
F
Well
you've
seen
it
at
least
once
since
this
is
out
of
this
week
and
here's
the
agenda
so
missus
administrivia
and
history
of
the
twelve
now
I
do
the
blue
sheets
are
going
around
and
we
do
have
a
jabber
scribe
and
minute
taker
who
will
then
go
through
a
requirement
presentation
and
then
two
shorter
presentations
about
the
proposed
solutions.
And
after
that
we'll
see
the
proposed
charter
and
have
the
Charter
discussion
and
the
usual
both
questions
and
after
which
we
can
to
either
talk
more
about
the
charter
or
more
about
the
requirements.
F
So
any
agenda
bashing,
no
good
so
about
the
process.
Well,
there
hasn't
been
any
decision
made.
The
is
G
is
not
has
not
decided
to
set
up
a
new
working
group
if
they
had
they
would
just
set
it
up
above
comes
to
answer
the
questions
about
whether
the
community
is
ready
for
a
working
group.
So
it's
not
a
foregone
conclusion
and
the
most
important
output
of
this
meeting
is
whether
we
are
recommending
to
the
ISD,
because
ultimately,
it's
their
decision
to
form
a
working
group
or
not.
F
So
if
the
answer
is
yes
and
then
we
have
still
not
decided
on
the
solution
and
we
still
haven't
decided
the
requirements.
There
is
a
requirements
draft
or
is
a
requirement
presentation,
but
the
requires
are
not
final.
They
are
still
up
in
here,
and
so
we
can
add
requirements.
Remove
requirements
dispense
with
them
entirely
and
do
something
else.
Anything
goes.
E
A
G
A
A
Okay,
so
that's
like
maybe
more
than
50%
of
the
room.
How
many
people
think
how
many
people
are
there
for
whom
this
is
a
totally
new
thing,
only
a
few
okay,
so
I
guess
for
the
presenters,
then
I.
Don't
you
don't
need
to
kind
of
go
to
excruciating
background
from
for
most
of
the
room,
I
think?
But
if
you're
in
the
room-
and
you
haven't
been
familiar
with
this
before
then
you
know-
let
us
know
and
ask
the
presenters
clarifying
questions
as
needed.
F
A
So,
just
plus
an
ad
goes
to
Mike.
We
wanted
to
just
have
clarifying
questions
at
these
for
these
three
presentation
slots
and
then
have
discussion
after
those
have
happened
because
again,
most
of
you
are
familiar
with
a
lot
of
this.
So
you
know
hopefully
don't
need
to
do
too
much,
both
very
clarifying.
A
H
At
least
this
was
this
was
a
security
ad
summary
of
the
discussion
insect
dispatch,
as
you
can
see
from
the
Charter
yourself,
so
have
a
look
now,
we've
come
to
the
Charter,
that's
not
the
end
of
the
presentations,
and
this
is
not
a
new
subject
in
the
ITF.
It's
been
on
the
agenda
for
since
2016
I,
think
and
extensively
discussed
during
spring
with
a
virtual
interim
dedicated
to
this
topic.
H
After
this
virtual
interim
I
was
asked
to
compile
the
requirements
summarizing.
The
discussion
and
I
did
that
and
I
got
some
more
comments
and
I
updated
that
that's
the
version
we
are
going
through
in
this
live
set
right.
So
first,
a
couple
of
slides
on
well
score,
if
you're
not
familiar
with
with
that.
H
So
Oscar
is
a
communication
security
protocol
for
coop
and
it's
basically
intended
to
protect,
what's
called
a
co-op
request
response
right
layer
which
is
the
upper
sub
layer
of
co-op
and
people,
so
you
can
think
about
it
like
a
rest
layer
and
including
things
like
protecting
payload,
your
eye
paths
and
code,
and
it
doesn't
protect
things
like
the
messaging
sub
layer.
That's
lower
sub
layer
of
coop,
which
is
the
binding,
the
UDP
and
therefore
it's
suitable
for
it's
easy
to
change
transport
protocol
without
changing
the
protection
of
of
the
actual
rest
message.
H
H
So
that's
just
a
background
here.
Some
examples
over
here
where
our
score
is
being
used,
applied
a
number
IDF
working
groups
and
also
other
IOT
for
us
or
other
either
specifying
its
use
or
referencing
it
or
has
shown
an
interest
to
deploy
or
score
and
on
the
right
to
see
a
number
of
development
and
testing
activities
which
includes
things
like
hackathon
activities.
The
multicast
was
tested
day
before
yesterday
in
the
interrupt
test,
a
number
of
open-source
projects
and
other
things
going
on.
H
Obviously,
if
you're
gonna
be
in
a
key
exchange
protocol
for
all
score,
you
need
to
provide
the
input
and
be
transported.
That's
all
score,
so
Oscar
needs
a
master
secret.
That's
used
for
driving
the
encryption
keys
and
this
master
secret
should
have
the
good
properties
perfect
for
secrecy.
A
good
amount
of
randomness
one
score
also
needs
to
have
sundry
T's,
which
are
peer
identifiers
and
then
intubation
should
be
able
to
be
arbitrarily
short
because
they
are
sent
in
each
message,
and
we
also
need
cozy,
algorithm
switches,
encryption
and
hkpf
Albertans
used
by
Oscar.
H
Okay,
next
is
authentication
credentials
and
for
since
their
various
different
kinds
of
IOT
deployments,
we
need
both
to
have
symmetric
and
asymmetric
and
circling
deployments
are
only
pre
shared,
so
you
have
provisioning
appreciate,
keys.
That's
important
and
republic
keys
also
have
a
natural
role
in
in
IOT
deployments,
and
you
don't
want
to
send
certificates.
H
I
H
I
I
D
I
K
M
K
And
Eric
is
trying
to
ask
about
how
you
translate
to
do
bits
on
the
wire,
whether
you
are
gonna
say:
I
have
a
rock
with
a
key
and
I'm,
always
sending
the
full.
You
know
hover
my
octaves
above
a
key
or
if
you
might
also
want
to
consider
a
case
where
the
two
parties
house
and
through
the
auto
pan
database
to
say
I'm
gonna,
send
you
the
octet
five
and
you
secretly
know
that
that
matches
to
the
your
active.
H
H
H
And
then
we
come
to
the
lightweight
part,
which
is
what's
been
discussed
most
so
the
light.
What
you
mean
by
light
weight
is
that
it
should
be
low
in
resource
consumption,
as
measured
by
fights
on
the
wire
wall
clock
time
to
complete
so
from
starting
with
the
protocol
to
the
and
power
consumption
and
amount
of
new
code
required
on
an
end
system,
which
already
has
a
no
score
stack.
H
Basically,
this
is
also
the
formulation
coming
out
of
of
of
the
secretary
discussion,
and
some
of
these
are
easy
to
quantify,
whereas
others
are
more
difficult
to
quantify
and
that's
basically
what
this
light
use
discussion
has
been
about.
How
do
we
quantify
this?
How
do
we
compare
two
protocols
and
say
this
is
a
better
protocol,
so
bytes
on
the
wire
is
fairly
straightforward.
H
If
you
look
at
the
message,
sizes
of
the
other
protocol,
light
on
the
wire
is
also
important
because,
as
we
shall
see
in
the
benchmarks
coming
after
this
slide,
it
impacts
time
to
complete
and
it
impacts
power.
Consumption
world
lock
time
can
also
be
translated
into
protocol
requirements
like
looking
at
round
trips.
So
as
few
round
trips
as
possible
is
sort
of
a
consequence
of
this
l1
here,
which
means
that
we
are
back
in
practice,
looking
looking
for
a
1:1
trip
protocol
which
is
mutually
CENTAC
ated.
H
So
when
you
have
at
least
three
messages,
power
consumption
is
one
thing
that
that
depends
a
lot
on
the
circumstances
of
the
deployment,
so
a
particular
radio
technology.
So
there's
one
of
the
benchmarks
is
looking
at
that
and
finally,
the
indication
of
the
sort
of
the
code
complexity
aspect
is
based
on
how
how
a
given
a
score
implementation
can
be
reused
in
terms
of
of
code.
H
There
were
three
benchmarks
presented
and
they
were
designed
by
experts
on
these
technologies,
and
these
three
are
specifically
relevant
to
us
core.
That's
why
they
were
selected
so
narrowband
IOT,
the
wrong
and
sixth
issue,
and
each
of
them
are
using
input
based
on
message
sizes,
which
is
specified
in
an
L
wig
draft,
and
the
task
of
comparing
security
protocols
was
also
a
task
that
was
given
to
us
during
this
long
period.
H
Looking
at
this
benchmark
and
this
this
spreadsheet
is
that
the
higher
message
overhead
results
in
higher
energy
consumption.
This
is
a
very
clear
correlation
and
it
should
doesn't
come
to
surprise
to
many.
So
so
the
requirement
here
is
the
AKS.
You
have
a
few
bytes
as
reasonably
possible
and
there
was
a
discussion.
What
is
reasonably
possible.
This
is
not
a
strict
engineering
requirement.
H
Is
the
clear
indication
that
message
size
matter.
So
that's
why
we're
focusing
a
lot
on
the
message.
Sizes
second
benchmark.
Looked
at
lower
warm
back
up
times,
so,
in
contrast
to
the
previous,
this
is
unlicensed
radio
and
therefore
there
is
regulations
for
how
much
you
could
use
a
certain
frequency
band.
So
there
you
need
to
make
it
back
off
period
after
transmission.
This
is
called
the
duty
cycle
and
the
benchmark
here
is
looking
at
the
European
setting
with
one
percent
duty
cycle
and
also
associated
data
rates.
H
So
the
benchmark
here
is
what
is
the
overall
wall
clock,
completion
time
for
a
key
exchange
protocol
using
packet,
size
or
51
bytes,
which
is
a
very
common
used
data
rate?
Some
networks
only
support
that
type
of
data
rates,
and
the
conclusion
again
is
that
there's
a
high
penalty
for
for
having
large
messages-
and
this
is
then
caused
by
the
by
a
need
for
fragmentation
and
having
to
wait
between
these
packets,
so
the
aka
should
fit
in
us
a
few
packets
as
possible.
H
That's
basically
that's
that's
the
second
requirement,
second
benchmark,
and
then
we
have
a
third
one
which
is
looking
at
sixty,
and
this
is
similar
to
the
previous
so,
whereas
in
in
our
band,
IOT
is
more
like
a
linear
function
of
message
size.
This
is
more
like
a
stepwise
function,
where
the
number
of
frames
needed
the
behavior
of
the
net,
that's
or
the
performance
of
the
key
exchange.
H
So
basically,
we
didn't
Ravello
this
formula,
uplink
down
quick
formula
which
led
to
any
statement
about
a
factor
3
instead
of
a
factor
2
point
6
between
between
the
different
compared
protocols
here,
so
it's
I
mean
the
main
conclusion
remains
the
same.
That
3
frames
as
possible
is
giving
this
optimal
performance.
These
numbers
were
taken
from
a
production
network,
sixties,
production
network
and
yeah,
and
also
all
these
rebound
smart
for
done
by
by
people
who
are
experts
in
these
this
field.
H
So
that
comes
in
the
last
slide
of
the
requirements.
Presentation
and
summarizing
it
in
aka
shows
support
P,
Shakira,
public
key
certificate
based
authentication,
negotiation
of
algorithms,
both
of
Scone
AKA
support,
the
same
transport
in
Oscar
and
the
protocol
of
the
protocol
run.
The
peer
should
agree
on
these
parameters
that
Oscar
is
using
and
it
shall
reuse
see
ball,
co-op
and
cozy.
For
loco
complexity
and
b3
pass
one
one
crib
a
smallest,
reasonably
achievable
to
fit
into
the
own
pockets
and
60
frames,
and
then
we
have
this
new
requirement.
Okay,.
F
N
Have
you
considered
as
a
requirement
or
not
a
requirement,
the
number
of
operation,
sometimes
that
late
will
be
run
on
the
right
timing
device?
Thus
what
sort
of
entropy
or
other
things
may
be
hope
we
afford
the
keys
and
they're
impacting
key
size
and
the
rest.
So
is
this
something
like
wife
and
device
that
this
only
gets
done
a
hundred
times
in
the
lifetime
device
or
this
something
which
no,
we
have
a
hundred
thousand
times
and
lifetime
devices
becomes
deformed.
So
we
have
to
concern
ourselves
with
this
sort
of
issue
since.
A
N
O
O
A
H
O
H
O
H
Yes,
okay,
the
point
is,
it
needs
to
have
this
is
so
this
formulation,
a
good
amount
of
randomness
is
a
quote
from
I
think
HKD
F,
but
it
might
be
some
other
coracii
so
and
the
purpose
of
the
assist
is
to
not
get
into
this
discussion,
but
basically
what
we
are
doing.
We
take
the
key,
and
then
we
use
hkpf
post
and
expand
and
the
other
mode,
and
then
we
use
it.
So
it
doesn't
have
to
be
uniform.
O
P
I
think
de
crimen
Smiths
are
the
privacy
aspects,
because
in
the
previous
dish,
comparison
between
ed
harken
and
DTLS,
it
should
be
noted,
they're,
providing
different
privacy
properties
and
of
course
they
come
at
the
cost.
If
we
strip
out
the
privacy
features
of
TLS
DP
less,
then
it
would
reduce
the
size,
but
that's
an
important
decision
of
whether
you
want
those
or
not
sure.
A
Q
E
R
Your
name
remains
tight
I.
Could
we
understand
the
background
off
the
street
boss
remark,
but
maybe
that's
the
water
but
I
have
a
more
general
question.
It's
a
student.
If
we
really
want
to
design
another
protocol,
you
can
set
the
problem
a
little
bit
broader.
If
you
look
at
some
of
the
applications
fences,
they
don't
just
have
an
authenticated
routing
protocol
there.
R
R
H
Many
things
that
you
can
expand
on
in
in
these
requirements.
The
problem
we
have
in
right
now
is
that
people
are
deploying
your
score
without
perfect
forward
secrecy,
and
we
think
that
this
is.
We
need
to
have
a
fix
for
that.
We
like
to
be
able
to
also
use
public
key
authentication
that
doesn't
exclude
that
there
are
other
ways
of
doing
this,
but
we
need
to
have
one
solution
and
not
wait
another
three
years
for
this
to
happen.
So
that's
my
high-level
answer
to
that.
A
H
So
let's
this
was
intended
to
be
an
overview
as
well
I'm,
sorry
for
making
many
slides.
This
is
an
equation.
13
and
I
just
want
to
talk
a
little
bit
about
how
it
matches
the
requirements,
and
we
can
probably
we
could
probably
skip
a
lot
of
this.
It's
a
sigma
best
protocol,
it
uses
Seaboard
sequences
of
zebra
elements
and
cosy
constructs
like
encrypted
sine
symmetric
and
asymmetric
versions
are
very
similar.
H
So
how
is
this
suitable
for
all
score?
We
have
the
connection
identifiers,
providing
the
Oscar
sender
IDs.
We
have
a
very
simple
negotiation
of
cipher
suites,
which
supports
negotiation,
alcoci
algorithms
and
we're
using
the
same
cosy
algorithms
on
my
honorary
distresses
of
scoring
group
what
score
and
it's
a
really
small
footprint,
because
it
reuses
Seaborg,
cozy
and
different
cause.
It
constructs
now.
The
constraint
features
of
this
protocol
is
that
it
supports
it's
a
little
bit
related
to
Eric's
question
about
how
we
identify
different
public
keys.
H
H
This
has
been
reviewed
since
2016,
but
there
are
lately
more
more
advanced
reviews,
there's
a
form
of
verification
on
broker
if
there's
another
one
on
Tamaran
ongoing,
and
there
were
two
crypto
panel
reviews
available
and
the
latter
one
on
them
provides
a
good
overview
of
the
protocol
and
all
of
the
comments
have
been
addressed
so
I
just
want
to
go
to.
This
is
my
last
slide
that
epic
actually
matches
the
requirements
and
it
performs
well
in
these
benchmarks.
H
So
there
are
constructed
image
here,
but
these
are
comparing
pre-shared
keys
piece.
Kd,
cd18
and
republic
is
using
the
three
benchmarks:
b1
b2
b3
in
the
previous
presentation.
So
first
you
see
the
number
b1
you
see
the
number
of
bytes
so
taking
the
PSK
first
b2
is
a
number
of
packets.
That
was,
if
you
remember
the
number
of
of
laura1
packets,
that
you
need
to
send
complete
the
protocol
and
that's
actually
one
message
per
packet.
H
So
we
need
to
have
multiple,
packets
and
frames,
but
if
you
compare
with
taking
sort
of
a
sigma-I
skeleton
top
at
the
bottom
right
and
you
take
the
common
crypto
objects
Isis
using
the
ephemeral
key
in
the
signature
and
the
Mac,
that's
how
this
is
like
sending
only
these
crypto
objects
in
the
messages
you
get
certain
message
sizes
and
if
you
see
how
many
packets
of
frames
that
correspond
to
that
those
are
exactly
the
same
as
we
get
walk.
So
it's
in
that
sense
optimal
from
the
point
of
view
number
of
number
packets
in
frames.
I
S
T
I
I
Yes
and
I
and
stuff
like
that,
and
so,
if
we
rate
to
be
able
to
like
have
something
where
you
could
like
leverage
the
ongoing
work
and
have
a
purple
line
of
protocols,
it
continues
to
enhance,
as
like,
the
sort
of
large
massive
work
that
already
is
going
on
in
TLS
continues
to
go
on,
but
as
you're
on
some
slides.
So
it
nicely
showed
it's
not
what
you'd
call
compact.
I
So
the
interesting
question
is:
can
you
continue
to
benefit
from
like
of
outline
of
real
all
that
line
of
work
and
the
continuous
lines
are
proven
in
patch,
but
also
have
a
compact
protocol?
Since
the
problem
like
that,
I'm
Richard
and
I
sorta
had
to
walk
on
their
truth
sort
of
two
general
approaches.
One
can
kind
of
take
here.
What
I
guess
when
you
who
call
on
like
cutting
fat
and
when
you
could
call
on
compression
so
the
cutting
fat
one
is
like
pretty
straightforward.
O
I
Keep
the
protocol
like
fill
in
general,
but
just
cut
like
ugly
encoding
overhead,
that
was
in
the
bespoke
service
protocol
on
coding,
like
no
one
ever
borrowed
optimize,
because
just
was
not
like
a
major
thing.
As
for
the
reference
point
like
if
you're
working
on
the
web
than
like
the
vast
majority,
the
data,
unlike
TLS
handshakes
in
the
web,
is
like
the
certificates
and
such
nobody
cares
about.
Like
you
know,
an
extra
20
bytes
here
or
there
on
the
protocol
certificate
is
the
big
thing
and
especially
like
an
quickly.
I
I
Bad,
but
is
there
because
encoding
so
there's
like
a
lot
of
places
with
length
fields
still
have
like
it'll,
be
like
well,
here's
like
something
which
is
a
length
and
then
like
here's
the
length
of
the
vector.
Oh,
that's
the
only
thing
in
that
thing
and
so
wait.
A
second
I
could
have
like
just
figured
that
there's
a
lot
of
places
where
they're
fixed
length
fields
that
like
actually
have
like
sizes
of
thematically
too
large,
for
the
thing
that
goes
in
them.
I
So
it's
like
very
common
to
see
like
yeah,
24
Whitefield
for
24
a
bit.
You
know
a
length
field
for
something
like
that:
education,
never
ever
a
larger
than
35
color
bytes.
And
so,
if
you,
basically
you
can
do
things
like
go
to
variables
interview
how
much
they're
on
coatings
there's
once
a
number
of
places
where,
if
they're
like
values
of
the
basic
or
implicit
on
some
particularly
redundancy
between
named
groups
and
key
shares,
Lee
actually
remove
the
couple
places
where
you
can.
I
We
can
shorten
like
so
excessively
one
crypt
of
variables,
like
just
a
random
value,
actually
to
be
32.
I.
Guess
there's
like
we're
kind
of
using
that
Frankie
downgrade,
but
if
you're
not,
if
you
have
system
where
you
don't
have
downgrade
problems
limit
issue
so
effectively,
this
gets.
You
like
at
a
lesson
point
three.
It
is
like
a
direct
one-to-one
correspondence
one
by
three,
which
is
like
that
tater
encoding.
I
You
can
almost
imagine
like
using
seahorse
like
that,
but
this
like
watching
so
this
sort
of
other
option
that
we
also
explored
is
basically
do
a
lot
more
of
nailing
things
down
and
removed
appreciation
for
things
you
didn't
ago
she
ate,
and
the
idea
here
is
you
probably
have
some
explosive
shape
parameter.
That
said,
this
is
like
one
of
the
18
profiles
that
I
have
them.
When
you
negotiate.
If
you
were
that
kind
of
stuff,
you
can
do
extraordinary
large
amounts
of
compression.
I
Basically,
by
like
we're
essentially
saying
well,
I,
don't
need
a
feel
so
I
know
exactly
I'm
doing
here,
and
so,
if
you
do
that,
then
you
can
actually
know
quite
a
bit
more
compression
and
there's
been
some
discussion
about
how
do
this
mechanically
on
basically
two
options.
One
is
to
treat
in
both
these
cases.
Actually,
one
is
to
sort
of
treat
the
wire
transcript.
Does
that
as
the
transferred
you
sign
over
and
the
others,
what
we
construct
the
original,
TLS
1.3
transcript
and
sign
up
for
that,
so
there's
advantages
in
both
designs.
I
Largely
yes,
depending
on
exactly
how
you
say
how
you
cut
things
up,
so
in
particular
on
so
one
thing
that
you
might
or
might
not
think
need
you
to
do
was
not
know
in
advance
what
your
duties
or
PSK.
So
if
you've
got
in
advance,
he
wouldn't
have
to
negotiate
that
right.
So
we've
been
a
bunch
of
back
and
forth
between
Richard
annoying
because
the
bhagavad
about
what
that
makes
more
sense
to
really
expand
the
transcript
or
not
the
advantage
of
each
man.
I
The
transcript
is
like,
then,
the
fruits
carry
over
as
long
as
Emma
straight
is
amorphous
on
the
compression
I've
questioned
their
cross
protocol
defense
in
that
case,
so
we're
working
with
with
Karthik
and
and
either
approach
of
these
has
a
pretty
reasonable
chance
to
keep
in
the
tail
4:23
all
the
cellist
machine,
everyone's
gone
through
valid,
which
Allah
knows
couldn't
easy,
don't
reuse
like
all
those
papers
that
people
did
in
Austin
protocol.
This
is
actually
much.
Is
it
pretty
straightforward
for,
like
the
symbolic
proofs
for
the
select,
the
more
detail
proofs
that
meet
us?
I
I
Just
to
keeping
what
concrete
isn't
what
those
looks
like.
Here's
an
example
of
the
client,
hello,
so
Gia's
client
hello,
is
like
notoriously
redundant.
So
you
know
we
have
this
legacy
aversion
which
nobody
uses
with
a
session
ID,
which
is
only
there
for
our
purposes,
not
a
lot
anymore.
So
there's
a
lot
of
redundancy
here,
also
a
fair
amount
of
scope
for
reduction.
Here's
an
example:
I
was
talking
about
with
Eli
fields.
You
could
have
65,000
bytes
of
cipher
suites,
which
is
roughly
32,000,
cipher,
suites
I.
I
Think
people
once
thought
you
might
want
to
have
so
again.
The
encodings
are
really
selectable
in
the
sense
that
in
the
sense
that
basically
tell
us
to
use
the
maximum
looping
coding
for
you
could
fit
for
the
old
times,
and
so,
if
you
ever
run
in
more
than
a
hundred
twenty,
except
for
sweet
that
had
to
have
65,
that's
pretty
gross.
I
I
So
this
is
the
if
you,
basically,
if
you
read
the
draft
like
basically
because
the
document
does
like
all
four
kind
of
transformations
everywhere,
you
can,
if
you
think
ruby
is
like
super
super
hyper
aggressive.
You
can
do
this
instead,
a
home
which
is
basically
say
well.
The
entire
handshake
shape
is
determined
external
eight
and
I'm
just
cut
that
wire
encodings.
U
Get
out
of
the
compression
approach
here,
if
you,
if
you
do,
is,
and
a
full
transcript
and
use
the
transcript
as
reinvests
like
the
key
schedule.
Is
that
even
if
you
do
use
some
out-of-band
negotiation
thing
to
set
which
sectors
which
you're
using
you
get
the
confirmation
of
those
that
the
negotiation
happen
properly
as
a
results,
the
key
scheduling
over
the
expanded
transcript.
U
I
Richard
Barnes
so
anyway,
I
would
say
either
of
these
we
have
like.
We
have
implementation
of
this
compression
approach.
We
have
partial
mutation
at
the
approach.
They're
perfect,
for
is
don't
I,
convinced
I
can
do
it
here.
Are
some
preliminary
results,
unlike
what
you
can
get?
If
you
do
this,
these
are,
as
you
can
see,
you
can
more
aggressive
the
compression.
This
is
like
that's
our
maximum
file
on
the
first
one.
Other
ones
aren't
quite
as
aggressive,
so
probably
the
biggest
major
contributor
to
the
biggest
sort
of
big
chunk
of
potential
reduction.
I
Here
after
you
shrink
like
a
ppl
were
more
aggressive,
is
the
Finnish
messages
which
are
super
large
and
clear
how
large
yep
to
be,
if
that's
exist
at
all
or
if
there's
a
way
to
turn
all
like
them.
So
that's
a
show
on
open
research
issue,
so
I
guess,
as
I
was
saying,
this
is
sort
of
like
the
first
cut
there,
a
number
of
obvious
places
to
remove
it.
The
next
steps
for
us
are
our
to
like
again,
let's
drink.
To
like
this,
has
lies
in
or
is
in
1
3.
I
It's
not
worth
doing
and
then
I
think
we're
trying
to
decide
internally
whether
we
like
this
compression
shot
is
you're.
Not.
It
has
some
really
obvious
advantages
in
terms
of
being
a
micro
really
tighten
the
screws
much
much
harder
in
a
particular.
You
know,
depending
on
which
profile
you
do
you
just
like,
can
Ruthie
move
run
and
see
otherwise
couldn't
remove,
and
then
this
transfer,
which
is
she
comes
up.
U
I
Think
one
of
the
one
of
the
virtues,
eventually
non-virtues,
depending
how
you
think
about
it
of
this,
is
that
it's
possible
to
design
a
especially
possible
design,
essentially
a
gateway
between
a
like
CTLs
back
in
the
TLS
stack
where
the
gateway
the
Gateway,
gets
the
traffic
keys,
but
does
not
get
access
to
the
the
endpoint
keys.
If
you
do
the
compression
approach
transcript.
So
if
you.
I
P
I
F
I
I
That's
probably
the
thing
that
I
think
is
both
sketchy
yeah,
supportive
on
justice
and
ankles.
That
would
let
you
put
lay
claim
in
a
purse
but
I
think
like
oh
yeah
yeah.
They
have
to
like
you
have
to
commissioners
of
that.
That's
probably
the
thing
I'm
like
most
resistant
to
pulling
out
I,
certainly
specially
shrink
them
quite
a
lot.
J
A
The
proposed
charter
proposed
so
we're
just
gonna
pop
up
the
proposed
charter,
and
then
the
my
clients
can
fly
so
essentially
this
is
I
think
it
was
said
earlier.
But
just
reiterate
this
was
the
output
essentially
of
a
bunch
of
discussion,
the
sector,
specialist
and
a
virtual
interim,
and
where
that
landed
so
far,
is
a
bit
of
text
the
beginning
and
to
think
about
a
working
group.
A
P
I
think
the
focus
on
us
for
alone
is
is
fetus
a
little
bit
restricted
for
me,
because
today,
the
way
how
people
deploy
AMD
is
using
GLS,
Nicholas
and
I
could
imagine
the
work
that,
for
example,
a
capper
scented
with
constraining
that
are
making
it
slimmer
would
be
perfectly
fine
for
them
without
actually
having
to
worried
about
Oscar
in
endurance
presentation
he
sort
of
mixed.
The
words
between
is
in
specifications
is
implemented
in
vistas
is
deployed
in
a
in
trouble.
Creative
ways
in
Oscar
is
not
as
widely
deployed
as
as
you
would
like.
P
X
H
H
Are
really
happy
to
use
that
or
for
the
things
we
have
TLS,
but
it's
it's
not
providing
most
optimal
solution
for
the
most
constrained
settings
and
that
I
think
so
there
is
actually
two
separate
questions.
One
is:
how
do
we
solve
the
very
constraints
of
things
where
we
have
today
are
using
Oscorp,
where
there
is
no
key
exchange
protocol
and
where
we
discuss
this
for
three
years?
Y
Y
So
one
of
the
things
I
saw
on
the
list.
That
kind
of
like
concerns
me
was
statement.
Well
we're
going
to
do
this,
but
we're
only
going
to
look
at
existing
key
exchange
protocols
and
not
allowing
a
new
and
then
you
have
a
new
set
of
requirements,
and
you
know
there's
two
ways
you
can
go
about
something
like
this
and
the
thing
I've
seen
working
groups
do
repeatedly.
Is
they
decide?
Ok,
we're
going
to
do
something
you
need
to
do
it
fast,
so
going
to
start
from
something
that
already
exists.
Y
We're
not
going
to
look
at
anything
new
whatever
and
we're
going
to
adapt
it,
and
then
they
start
with
a
set
of
new
requirements,
and
then
they
go
straight
into
a
rathole
and
it
takes
three
times
as
long.
So
it
looks
to
me,
like
you,
are
looking
at
a
new
key
exchange
rather
than
complete
reuse.
The
other
point
I
would
make
is
looking
at
the
three
choices,
the
one
that
I
would
go
to
without
what
mutating
technology
is
CTLs
and
the
reason
for
that
is
branding.
Y
There
are
implementations
where
I
can
you
know
if
I'm
using
DP,
if
I
want
to
use
DTLS
in
the
product,
I
can
usually
find
it
in
to
talk
it,
because
the
TLS
folks
said
all
right
about
TLS
might
will
be
out
in
DTLS.
I
will
probably
get
CTLs
as
well
free,
so
if
you
want
to
actually
make
use
of
that,
not
you
know
having
a
similar
name
is
very
useful.
However,
that
will
also
apply
before
the
deep
EF
or
GTS
as
well.
M
K
Here,
so
if
we
could
try
a
little
bit
to
think
about
sort
of
the
higher-level
question,
your
is
this
a
problem
that
we
want
to
solve
in
the
ITF
and
do
we
think
we
understand
the
problem
given
the
length
of
Mike
line,
you
know
maybe
having
a
creepy
mask
for
just
Vince,
it's
not
going
to
be
so
hard,
but
let's
turn
to
focus
on.
Do
we
understand
the
scope
of
the
problem?
We
had
some
proposed
requirements
that
we
saw.
You
know
it
may
be
thinking
about.
K
If
that's
in
the
right
space-
and
you
know
I
know,
Bob
came
up
to
ask
a
completely
different
sort
of
requirement.
You
that's
a
really
good
thing
to
be
thinking
about
the
high
level.
Is
this
the
right
problem
to
be
looking
at
I?
Think
Phil,
maybe
maybe
also
be
as
much
to
the
point.
So
that's
the
sort
of
points
that
are
really
good
to
be
hearing
about
I
love
that
we
have
people
thinking
about
the
technology
as
well.
If
you
could
try
to
keep
those
minimum
that
would
be
appreciated
and
Benjamin.
AA
AA
AA
There's
a
couple
different
reasons,
but
guest
is
always
done.
It's
too
heavy
weight
for
various
different
reasons,
be
happy
to
explain
the
over
beer
or
something
for,
but
really
I
mean
for
us
every
bit
on
the
wire,
and
it's
no
there's
no
wire.
It's
just
there
right,
but
every
bit
over-the-air
cost
money.
So
if
the
bigger
the
packets
are
this,
you.
AA
B
H
AB
AB
AB
E
I
And
that's
hot,
certainly
I,
don't
see
it
written
here,
target
good
question:
yeah
I'm,
generally
positive
about
this
further
I'm,
actually
depicts
which
I'm
happy
should
be
SME
more
I,
think
I
do
agree
on
partly
with
with
Hana
said
and
Iran.
Certainly
I.
Think
like
like
the
penny.
People
are
in
duo's
horses,
better
work
with
always
Clerk
I
think
it
would
be
sad
if
it
were
to
those
core.
I
I
I
I
AC
AC
E
AC
Pick
between
those
of
this
plan
perfectly
happy
with
a
charter
that
sort
of
has
us
go
forward,
thinking
about
which
one's
appropriate
gives
us
more
time
to
get
the
influent
a
ssin
experience
on
how
that
works.
I
understand,
you're
going
to
say
the
trigger
doesn't
say
that
was
close
being
discussed.
This
might
find
so
uh-huh
on
completely
other
comment.
I
just
was
shocked,
shocked
to
find
what
an
awful
job
that
see
a
lost
working
group
has
been
doing
under
protocol
and
I
hope
they
get
it
much
smaller.
Coming
really
soon.
F
P
Hannes
I
wanted
to
respond
to
the
question
of
like
is
this
Easter
problem
is
the
problem
to
be
solved
and,
as
you
know,
I
work
for
a
company
who
works
on
the
empathy,
l'estaque
an
open
source
and
very
idealistic.
You
know
so
the
boys
IOT
devices-
and
we
don't
have
these
problems-
that
some
of
the
other
people
are
reporting
today
like
we
can.
D
P
A
secure
IOT
devices
over
those
net,
those
networks
and
other
networks
as
well,
and
we
do
that
today
and
the
primary
reason
is,
of
course
we
can
always
cut
down
on
things,
but
we
try
to
look
at
the
whole
bigger
picture
and
the
bigger
picture
is
the
whole
lifetime
of
the
device.
What
does
it
do
at
the
beginning
of
onboarding?
P
This
is,
for
example,
the
firmware
update
what
we
have
to
cut
down
and
come
up
with
some
really
clever
techniques.
We
should
shrink
it
down
because
that's
where
the
battery
then
drains,
not
because
you
run
a
once
in
a
while
a
key
exchange
brother
:
in
this
mentioned
earlier.
We
had
already
extended
TLS
dude
already
from
right
from
the
beginning
to
do
session,
resumption
and
different
incarnations
of
special
resumption
to
actually
shrimp
and
shrink
the
things
done.
P
So
you
don't
have
to
exchange
all
the
certificates
and
there,
the
public,
the
diffie-hellman
body
keys
all
the
time.
And
so
that's
why
they
don't
see
that
those
problems
and
and
I'm
happy
to
talk
to
you
as
far
from
icon,
because
I
talked
to
one
of
your
colleagues
on
where
I
I
see
improvements
in
your
design,
gas,
water
metering
devices
I
mean
having
said
that,
since
I've
been
working
on
making
Heelys
better
suited
for
a
devices
to
shrink
them
down.
I'm
happy
to
see
the
work
that,
like
Colin,
said
to
cut
down
on
here.
Lesson.
P
Dtls
and
I
push
Gurgaon
and
in
you
and
many
other
Erickson
colleagues
would
come
along
or
I
would
have
come
along
years
ago
to
come
to
the
DLS
working
group
to
actually
help
out
with
some
of
the
things
where
I
was
always
sitting
alone
and
talking
to
50
bad
people
who
care
part
of
the
different
things
about
quickens
on
itself.
So
yeah.
AD
If
I
would
Patrol
so
in
my
company
we
have
developed
a
horse-collar
implementation
and
we
are
interested
in
everyone
networks
which
are
very
constrained
for
some
of
those
guys,
it's
very
important
to
have
small
implementations
and
the
possibility
to
reuse
them,
components
that
are
already
there
for
Oscar
for
this
protocol.
I
think
it's
something
that
might
be
very
helpful,
and
this
is
certainly
some
work
that
will
be
very
interested.
G
Mallesh
origin,
so
speaking,
probably
on
behalf
of
the
six
working
group
I
just
like
to
make
some
couple
of
clarifications.
We
are
using
horse
cotton
and
adopted
working
of
documents
or
since
three
years
now,
for
two
years
ago,
we
asked
Rob
one
meeting
during
the
during
the
premier
click
on
the
egg
for
our
score.
G
So
for
us
this
was
really
to
do
designing
an
egg
for
our
score,
satisfying
these
requirements
that
you
are
on
presented,
and
mainly
the
trans
through
supporting
the
transports
that
Oscar
supports,
while
staying
efficient,
so
I
would
just
I
think
it's
good
that
we're
having
this
discussion
today
and
that
we
are
having
opposing
solutions.
But
for
us
for
us
in
six
dish.
This
boils
down
to
the
requirement
problems
cope
with
designing
the
next
prosper.
F
Yeah
Eric
Erickson,
so
I
think
this
is
what
should
go
ahead
and
I'd
like
to
see
our
score
and,
and
then
working
group
will
move
forward
or
okay
and
what
do
to
movin
forward,
and
if
that
that
shouldn't
preclude
also
work
on
CTLs
or
DTLS
developments.
I
would
like
to
see
that
and
I
just
want
to
generalize
my
comment
a
little
bit
that,
like
it
it's
in
all
the
we
sometimes
in
in
the
in
the
idea
they
are
very
focused
on
translators,
give
at
the
end
there.
F
Where
you
actually
need
something
else,
and
it's
not
a
one
size
fits
all
situation,
necessarily,
that's
probably
part
of
the
reason
why
we
haven't
always
worked
on
that
one
Peggy,
TLS
and
so
forth,
but
there
are
other
things
as
well
and
I
think
we're
starting
to
see
the
effects
of
only
focusing
on
one
thing.
In
the
broader
we
also
have
to
look
at
when
psyche
begins
in
cases
across
transport,
ops
and
so
forth,
so
that
doesn't
apply.
AE
Michael
Richardson,
so
I've
implemented
six
dish
brueski
over
T,
TLS
and
I
could
talk
a
lot
about
some
of
the
interesting
problems
with
threading
models
that
happen
with
available
libraries.
Those
are
implementation
issues,
but
one
of
the
arguments
for
as
Phillip
said
you
know
about
something
TLS
that
you
get
to
download
the
standard
libraries
that
people
use
everywhere,
which
means
that
you
actually
have
the
the
advantage
of
an
existing
system.
The
disadvantage
is
that
you
have
to
cope
with
the
existing
system.
AE
Okay
and
you
have
to
figure
out
whether
or
not
I
am
willing
to,
as
heinousness
company
has
done.
If
you
rewrite
it
all
from
scratch,
okay,
or
go
with
something
else
and
figure
out
how
to
make
it
work.
So
one
of
the
interesting
things
about
the
way
that
people
have
learned
co-op
servers
is
that
they
tend
to
process
one
request
per
thread
in
a
thread
pool,
and
this
totally
doesn't
work
as
soon
as
you
put
a
security
context
around
it.
AE
Now
it
probably
doesn't
work
regardless
of
whether
the
security
context
above
co-op
or
below
that
just
to
be
clear,
but
the
current
set
of
libraries
that
we
have
forces
you
to
do
it
in
a
particular
way.
So
that's
something
I
want
to
say
that
that
in
the
space
of
co-op
asks
which
is
co-op
over
DTLS,
we
have
within
that
a
nother
layer
of
OS
core.
Once
you
get
things
going,
okay,
whereas
what
we're
trying
to
do
is
actually
key
OS
core.
We
don't
actually
want
to
run
co-op
over
a
DTLS.
AE
We
want
to
key
OS
core
and
then
just
run.
Let
co-op
run
okay
and
that's
why
we
get
the
transport
agility.
Okay,
through
other
things
and
possibly
through
several
layers
and
I-
think
that's
something
that's
not
captured
in
the
chart.
I,
don't
have
a
specific
suggestion,
but
I
don't
think
that's
captured
in
the
Charter,
okay
and
I
have
see
CTLs
I.
Would
love
to
I
would
prefer
that
over
in
their
co-op
est,
spec
I
would
prefer
that
we
just
went
with
that
like
tomorrow,
make
it
C
work.
K
K
So
you
said
that
right
now
in
the
stuff
with
you
menteng,
you
do
DTLS
and
you
run
co-op
mouse
over
that
and
within
the
co-op
apps
you're
carrying
OS
core
messages
that
correct,
and
so
what
you
would
like
to
be
doing
instead
is
to
not
have
the
DTLS
layer
and
to
say
we're:
gonna
run
a
lightweight
we're
gonna
key
or
a
support
directly
and
just
be
sending
you
saying:
go
escort
over
the
wire
or
go
out
without
the
coop.
That's
the
other
detail.
K
AF
T
I
just
wanted
to
I
wanted
to
point
out
an
observation.
Somebody
who's
really
only
been
following
this
work
from
several
re
distances
away,
and
that's
that
I've
heard
a
lot
of
people
come
up
to
the
mic
and
say:
oh,
it's
easy,
because
we
have
this
other
similar
thing
that
we've
done
that
if
you
just
change
everything
about
it,
it'll
totally
be
this
new
thing
and
isn't
that
simple
and
I
think
that
that's
paraphrasing.
T
So
I
just
wanted
to
say
that
anybody
who
claims
that
you
know
and
I
heard
this
from
from
multiple
people
with
multiple
backing
multiple
different
technologies
going
into
this
make
similar
claims
today
that,
if
somebody
is
telling
you
oh
yeah,
we
we
just
changed
everything
and
it
works
fine
on
our
little
bespoke
box.
That's
not
gonna
scale
as
well
as
maybe
you
might
think
I.
E
P
Kind
of
like
to
follow
up
on,
but
Michael
said
previously,
and
it
it
sounds
like
an
easy
thing
to
just.
We
implement
these
and
just
do
something
else
and
create
something
new
from
scratch
on
and
be
done
with
it,
but
probably
Brandon.
That's
why
we
have
a
team
of
getting
Plus.
People
are
working
more
than
10
years,
for
this
is
because
the
innovative
its
face
is
somewhat
hard.
There's
lots
of
different
hardware.
P
There
are
lots
of
different
operating
systems,
built
them
operating
systems,
some
people
rare
a
trauma,
clear
metal,
and
then
you
have
to
integrate
it
into
into
the
IDS
as
well
to
make
the
experience
a
little
bit
smoother,
and
that
takes
a
lot
of
time
and
I'm
curious
on
who
is
essentially
writing
this
new
embedded
security
stack
for
at
work
and
in
maintain
it
for
then
something
years
coming
before
it
a
feature
that
will
come
along
integration
of
hardware,
secure
things
on
I.
Think
people
underestimate
the
bring
the
effort.
P
What
looks
like
a
hackathon
project,
a
one-off
thing
is
actually
much
more
working.
I
was
astonished
myself
when
I
saw
it.
It
looks
like
implementing
some
of
the
extensions
that
come
out
of
the
pls
working
is
so
easy,
but
if
you
have
to
make
it
work
for
many
many
different
devices,
it's
difficult
I'm,
just
it's
not
a
joke,
I'm,
not
making
yourself.
You
look
at
the
look
at
our
verbosity
and
how
many
contributors
down
on
how
many
Hardware
black
homies
runs.
It's
good.
U
Richard
burns
again,
I
just
want
to
clarify.
When
did
I
heard,
a
couple
of
people
raise
an
idea
that
you
know.
Cto
of
this
district
could
do
things.
He
could
progress
a
lot
on
TLC's
I.
Don't
really
think
that
CTO
is
actually
makes
sense
as
a
TLS
work
right,
because
if
you
were
going
to
design
a
compactive
compactify
to
compress
402
us,
you
have
these
questions
of.
When
you
have
these
questions
of
the
trade-offs
between
rigidity
and
size
that
you
want
to
negotiate.
D
U
I
have
a
second
point,
and
similarly
you,
the
structure
of
the
compactive
education,
depends
very
much
on
the
environment
in
which
is
going
to
use
I.
Think
yes,
CTLs
is
going
to
be
done
again,
not
saying
that
it
needs
to
be
the
outcome
here.
But
if
it's
gonna
be
done,
I
think
it
needs
to
be
done
in
a
context
that
has
all
the.
V
V
Gonna
take
something
and
just
make
a
few
tweaks
to
it,
to
make
it
something
completely
different
and
it's
all
going
to
be
fine
and
we
don't
even
need
an
RFC
and
we'll
do
this
quick
and
it
kind
of
scares
me
maybe
I
just
understand,
what's
going
on
with
the
intended
work,
but
it
seems
to
me
from
my
perspective
is
that
we
need
a
different
Keen
protocol
and
we
should
address
that
appropriately
with
the
right
amount
of
resources
coming
in
I,
get
a
little
nervous
about
saying.
Oh
we're,
just
gonna
change
a
little
bit
feet.
A
Just
to
kind
of
at
the
point
about
the
bit:
that's
not
an
RFC
would
be
just
a
requirements
document
there's
a
there's,
a
history
in
the
IETF
of
people,
writing
requirements,
documents
and
then
everybody's,
so
bored
with
them.
But
by
the
time
you
get
to
try
and
turn
in
tomorrow,
see
it
just
turns
into
a
crap
fest
so
that
it's
it's.
V
Y
Just
to
clarify
my
earlier
remarks,
I
was
not
suggesting
doing
TLS.
This
needs
to
be
in
that
separate
working
group
and
with
all
the
will
in
the
world.
Yes,
we
can
try,
it
hope
to
reuse
troops
and
so
on.
But
you
know
at
the
end
of
the
day,
their
victim,
more
or
less
free
they've
got
infinite
numbers
of
grad
students.
L
L
On
the
other
end,
when
we've
received
the
frame,
we
see
that
okay,
we
know
that
the
first
bytes
are,
you
know,
person
up
for
treatment
or
sure
it's
2,
1
4
3
Rd
X
money
there,
and
in
this
way
you
can
always
you
know,
compress
the
frame
with
the
static
header
of
there.
If,
if
we
ever
come,
you
know
meet
some
extensions
or
something
like
that.
We
can
create
a
new
study,
cater
conferencing.
AB
L
J
AB
AB
K
AB
Constraint,
people
really
have
this
wonderful
and
it's
a
huge
at
some
point,
and
then
they
can
just
commit
against
that.
But
I
think
that
how
things
are
actually
touching
TLS
and
doing
this
in
a
way
that
that
it
doesn't
break
it
now.
I
have
a
draft
from
2013
that
describes
how
to
hit
a
compress
DTLS.
AB
So
that's
not
that
hard
at
this
period
of
mine
wrote
that
most
of
it.
The
problem,
of
course,
is
that
the
way
fearless
is
defined
there
is
there.
Are
these
wonderful
finished
messages
and
they
work
on
what
was
on
the
wire
and
if
you
compress
it,
it's
not
the
same
thing,
so
you
actually
have
to
construct
the
entirety
of
the
messages
in
memory
before
you.
You
are
able
to
construct
that
fresh
message.
So
thinking
about
the
finished
message
is
probably
the
most
important
new
thing
I'm
taking
over
from
the
discussion
yeah.
U
Importance
of
the
two
sides
of
this
relationship
because
I
think
it's
not
like
the
things
you
are
least
mayor
would
seem
the
hardest
so
like
coming
from
a
TLS
back
on
the
IOT
that
doesn't
seem
harder
to
me.
It's
living
it
until
it's
consumer,
yeah
I.
Remember
the
second
thing
that
we
would
need
out
of
this
community.
If
you
were
gonna,
do
a
protocol
like
this,
which
is
you
know,
Collins
this
a
ke?
AG
So
it
seems
like
from
reading
the
this
and
from
the
discussion
today
there's
an
implicit
shared
notion
of
what
all
the
costs
are
and
I
think
it's
totally
reasonable
for
everyone.
This
think.
Well,
what
bites
on
the
wire
are
extremely
expensive
because
indeed,
it's
very
expensive
to
some
things
over
wireless,
like,
on
the
other
hand,
it
may
be
the
case
that,
like
it,
would
be
useful
to
make
explicit
the
suppose
it
costs,
so
it
may
be
that
they
would
be
useful
to
have
multiple
models
you
know.
AG
So
the
cost
is
this
for
this,
this
sort
of
thing,
because
it
might
be
that
at
the
end,
for
example,
you
want
to
really
crush
the
cost
of
crypto,
and
so
it
doesn't
make
any
sense
as
very
specific
example
to
use
hkpf
with
a
sponge
fashion.
Maybe
you
could
say
a
little
bit
of
the
work
there
and
I
don't
know,
but
it
may
be
the
case
that
some
people.
AG
About
making
that
better,
so
it
might
be
like
as
a
next
step
as
part
of
number
one,
a
useful
thing
to
specify
in
some
reasonable
detail
what
the
assumptions
are
about
costs
of
various
things,
because
if
the
only
thing
you
care
about
is
saving
bytes
on
the
wire
that
it
seems
totally
reasonable
to
compress
TLS
and
call
like
done.
But
it
may
be
that
that's
not
what
you
care
about
and
therefore
that
might
not
end
up
being
the
correct
thing.
Big.
P
K
Been
Caidic
stopping
back
into
check
by
with
the
valve
questions,
we
do
have
almost
like
I'm
really
happy
to
hear
you
know
the
interests
people
have
and
support
forward
in
space.
I
think
you
know,
the
critical
mass
of
people
is
pretty
good
at
control.
We're
talking
about
the
problem,
which
is
good,
I'm,
actually
really
excited
to
see
the
discussion
about
the
scope
of
the
problem.
K
So
we
had
several
people
come
up
and
give
some
things
that
we
might
want
to
think
about
for
the
requirements
document
that
we're
not
mentioned
in
the
slides
you're
like
I
was
mentioning
the
number
of
aches
we're
actually
gonna
do
over
the
timescale
on
the
device.
You
know
how
important
that
stuff
for
the
battery
life,
how
are
we
can
integrate
with
those
for
that
I
think
Richards,
imagining
as
I
think
that
the
TLS
experts
would
not
be
able
to
do
how
a
generic?
K
How
specific
do
we
need
to
be
how
how
tightly
coupled
do
the
requirements
that
we
come
up
with
or
arm?
Its
document
need
to
be
with
the
use
cases
that
we
are
currently
looking
at,
how
extensible
or
flexible
do
we
want
to
do
if
you
use
cases,
the
immediately
previous
speaker,
I
think
was
talking
about
what
are
the
assumptions
about
costs
that
we're
making?
K
H
So
a
couple
of
things
if
I
can
remember,
starting
with
this
point
on
assumptions,
costs,
but
that's
basically
what
we've
been
doing
in
the
safety
scratch
work
with
the
benchmarks,
and
it
turns
out
that
this
is
not
so
easy
to
get
all
the
cost
exactly
right.
So
you
need
to
make
assumptions
and
weighting
in
order
to
make
a
hard
measurement
about
saying
this
is
a
good
property,
and
then
you
need
to
make
assumptions
and
that
those
assumptions
are
based
on
something.
H
H
H
Then,
coming
back
to
the
solution,
space
I
think
it's
important
here
to
understand
it's
that
the
optimal
solution
probably
isn't
CTLs
in
the
it
is
not
in
the
most
compact
and
aggressive
as
we've
seen
here,
I
mean
that's,
definitely
not
as
lightweight
as
as
they
the
protocol
I
was
showing.
So
at
some
point
we
need
to
make
the
choice.
Are
we
going
to
do
an
isomer
field
of
TLS?
H
D
K
A
A
It's
not
clear
to
me
how
and
whether
it
is
anything
we
could
put
in
the
Charter.
That
would
help
and
would
be
great
if
there
is,
but
how
does
that
requirements
discussion
terminate
to
allow
the
second
part
of
the
work
to
continue
is
not
clear
to
me
and
if
people
have
thoughts
on
that,
I
think
it
would
be
interesting.
AH
And
so
the
question
is:
are
we
solving
the
problem
or
is
meaning?
Is
the
problem
too
narrowly
described
or
is
the
program
of
work
too
broad
and
I?
Think
that's
the
question
that
funnest
was
asking
and
that's
right
here
at
which
people
at
the
mic
talking
about
so
far,
I
have
heard
a
bunch
of
support
and
minds
and
from
what
I've
heard
for
solving
something
with
it
özgür
and
if
it
can
be
used
with
other
stuff
too.
R
E
P
Facet
to
this
problem
statement
and
cuz,
he
mentioned
that
she
would
like
to
see
something
on
object,
level,
security
and
funny
enough
Oscar
doesn't
to
object
level
security
in
the
adls
document
that
I
mentioned
earlier
I
described
or
we
described
how
to
derive
keys
from
cozy,
which
provides
object
ever
security
and
I.
Think
that
would
also
be
very
useful
because
we
have
a
number
like
in
suit.
We
have
a
number
of
cases
where
we
actually
want
to
protect
individual
bailouts,
and
we
may
also
need
a
key
management
protocol
for
them
and
I.
Think
that's
good.
P
It's
someone
said
earlier.
They
wanted
to
add
this
or
point
out
that
authorized
protocol
agnostic
and
that's
all
also
only
partially
true
I-
think
there's
a
little
bit
of
over
advertisement
here,
because
it's
true
when
the
stuff
that
comes
in
and
the
stuff
goes
out
actually
is
the
rest
protocol
and
has
the
same
protocol
semantics,
and
we
talked
about
the
Itron
case.
Previously
you
are
protocol
you're,
probably
using
is
not
what
is
probably
not
most
of
the
guys
going
on
use
MQTT
like
Amazon
Google
Microsoft,
not
a
restful
protocol.
O
Taking
forever
reminds
me
of
my
experience,
I
am
one
of
the
chairs
who
survived
the
long-running
TCP
Inc
working
group,
which
might
have
been
what
he
had,
and
so
let
me
offer
one
thing:
concrete
piece
of
advice
base:
what
happened
a
TCP
Inc.
It
would
be
irresponsible.
The
iesg
to
charter
working
group
here
without
picking
the
core
protocols
start
from.
O
So
responsive
harnesses
comma,
which
is
my
thing,
is
you
make
tough
decisions?
No
I
am
saying
that
when
me
ie,
when
the
Charter
comes
out,
the
toughness
is
just
happy
me
I,
don't
care
by
whom
I
don't
care
by
how,
but
they
must
be
made,
though
otherwise.
Those
who
fail
to
learn
history
will
be
condemned,
repeating
yourself
working.
F
O
D
AB
Stage
use
requirements
a
lot
and
there's
something
called
requirements:
engineering
that
may
not
be
way
off
requirements.
Engineering
is
engineering
the
requirements
in
such
a
way
that
your
solution
comes
out
as
the
one
that
is
chosen
and
so
work
on
the
requirements
always
is
tainted
by
this
problem,
and
we
shouldn't
be
spending
a
lot
of
time
honing
this
these
requirements,
knowing
that
there's
just
energy
that
is
dissipated
from
from
actually
doing
the
work
having
somebody
about
the
wires
is
good,
but
this
is
not
something
that
we
should
spend
a
lot
of
time.
F
So
I
think
that
by
the
time
the
requirements
are
finished
and
that's
something
that
we
want
to
work
in
work
to
do
and
either
one
of
the
proposals
doesn't
meet
the
requirements.
And
then
it's
off
the
table
anyway
or
both
meet
the
requirements.
And
then
we
could
decide
by
quintus
if
there's
no
clear
majority
in
the
room
for
one.
Z
AH
AC
Group
had
a
much
more
difficult
decision
about
this
about
a
video
codec
to
use,
and
there
was
no
way,
though
I
understand
the
pain
of
the
TCPA
working
group.
You
know
I
get
the
point.
We
would
never
have
managed
to
come
to
a
decision
on
that
topic.
Had
we
not
had
awfully
4
years
of
repeated
discussion
about
it
in
working
group
meetings
and
we
came
to
a
solution
that
was
pretty
good
and
I
believe
that
we
would
never
charge
WebRTC
if
we
decided
we
would
have
had
to
make
that
decision
before
we
charter.
H
So
we're
spending
four
years
more
to
try
to
find
finding
some
solution.
Maybe
we
didn't
manage
and
maybe
a
lot
of
applications
are
being
used
without
forward
secrecy
and
we
don't
have
a
good
key
management
protocol
for
school
I.
Don't
think
that's
a
very
good
solution,
but
I
mean
we
basically
came
to
this
room
to
try
to
find
a
solution
for
all
score.
Q
H
Y
Just
want
to
push
back
on
the
idea
that
picking
one
protocol
is
necessarily
going
to
speed
things
up,
because
my
experience
is
that
when
you,
when
you
come
in-
and
you
start
from
a
particular
starting
point-
they
said
we're
gonna
pick
this
winner,
but
we've
got
all
these
other
requirements
and
so
we're
going
to
start
changing
it.
It's
cuz,
it's
like
if
you
start
off
from
the
idea.
Y
Well,
we
want
a
house
but
we're
going
to
remodel
it,
and
then
there
is
a
certain
point
way
seems
like
the
easiest
thing
to
do
is
to
start
from
a
house
and
just
remodel,
and
you
know
replace
things,
but
you
know
after
I
had
replaced
my
roof.
My
walls,
my
foundation
and
so
I've
actually
rebuild
my
house
now
twice
and
you
know
I've
seen
this
happening
working
groups.
You
know
I've
been
in
working
groups
where
people
have
said
in
the
chartering
discussion.
Y
We
have
to
have
this
done
in
a
year,
so
there's
no
time
to
think
about
it.
We
must
do
it
now
and
five
years
later,
they're
still
at
it,
and
this
working
group
has
failed
because
they
chose
the
wrong
protocol
to
try
and
do
it
fast.
So
I
don't
think
that
there's
a
sounds
like
it's
going
to
be
shortcut,
but
my
experience
is
that
it
isn't.
I
J
I
AA
AA
That
is
that
doesn't
see.
These
are
very
different
audiences
that
the
embedded
audience
is
actually
doesn't
really
have
a
lot
of
differences
from
the
non-embedded
audience
and,
if
you're,
if
what
you
care
about,
is
streaming
video
VPNs
and
the
the
privacy
of
your
browser
identity,
you're
at
odds
with
what
embedded
needs.
So
when
do
we
like
clearly
that
split
happened
with
co-op
in
HTTP?
So
when
do.
AH
And
the
questions
that
you're
going
to
ask
right,
you're
gonna,
ask
about
if
people
understand
the
problem
and
as
the
print
and
is
there
gonna
be
a
scope
right,
I
think
what
I
heard
is
that
people
do
understand
the
problem,
but
there's
two
different
problems:
there's
the
narrow
problem
of
house
corner
and
there's
the
wider
problem
that
the
milestones
currently
address.
Okay.
So
when
you
ask
for
questions,
if
you
can
ask
it
in
a
way
that
doesn't
presume
that
everyone,
everybody
has
the
same
problem
in
mind,
even
though
everybody
has
a
well-defined
problem.
AH
I'm,
going
back
to
the
discussion
that
Eric
and
I
had
at
the
mic
when
I
last
time,
I
got
up
to
the
mic.
I
said
the
goals
and
milestones
are
much
wider
phrased
than
escort
okay
and
so
for
some
people
here
the
problem
is
the
one
that
the
milestones
as
worded
address
about
can
hae
for
constraining
devices.
AH
So
my
question
is:
when
you
ask
your
questions
on
the
next
slide,
if
you
can
ask
them
in
a
way
that
helps
me
figure
out
how
to
answer
the
question,
because
I
don't
know
which
clutch
that
you're,
asking
as
they
are
phrased
in
the
generic
sense
right,
the
way
that
their
creation
to
how
to
have
run
successful
BA
whose
copy
the
questions
it
doesn't?
You
just
copy
the
phrasing
it
doesn't
accommodate.
There's
two
different
views
of
what
the
problem
is.
So
I
will
sit
down
now,
but
okay.
Z
AH
F
F
M
AH
Okay,
do
you
understand
the
issues
Perl
is
when
you
say
is
this
a
problem
that
needs
solving?
You
can
split
that
into
questions
is
as
corner
key
change.
A
prominent
needs
solving
and
is
generalized
constrained
scenario
than
which
is
much
larger
problem.
Is
that
one
that
needs
solving?
Those
are
two
different
questions.
Okay,
when
it
says
is
this,
a
problem
implies
there's
only
one
problem
here,.
AH
AH
A
A
A
A
D
AE
I'm
a
having
been
through
the
space
and
implemented
in
use
lots
of
Hanna's
code.
My
experience
is
that
if
you
have
enough
code,
space
and
network
space
and
others
power
to
run
any
TLS,
those
extra
bytes
don't
matter.
On
the
other
hand,
if
you're
really
constrained,
then
you
really
doesn't
matter
so
there's
a
kind
of
a
step
function
where
it.
AE
If
you
can
run
a
little
bit
of
TLS,
then
you
probably
can
run
a
fair
bit
more,
and
how
does
this
point
to
the
fact
that
you
don't
do
a
lot
of
akes
over
the
lifespan
of
the
device?
It's
probably
relatively
true,
and
so
I'm
not
sure
that
that
if
you
really
want
to
do
run
empty
qmq
today
and
the
qtt?
Thank
you.
I've
never
was
get
it
wrong.
AE
P
M
A
So
when
I
turned
home
anyway,
I
think
I
had
a
very
big
home
positively
and
a
few
people
who
then
happily
came
to
the
mic
and
give
us
some
negative
reaction.
So
I
think
the
other
questions
don't
need
at
it.
So
it's
the
ITF
the
right
place
to
solve
to
work
on
this.
If
you
think
it
is
from
that,
if
you
think
the
IHF
is
not
the
right
place
from
nothing,
thank
you
were
you
hoping
it
was
at
you
all.
Q
A
A
Q
A
So,
in
terms
of
the
deliverables,
this
is
the
idea
of
working
the
requirements
text
and
then
not
throwing
it
in
our
C
and
then
documenting
a
protocol.
I
think
do
you
understand
what
the
deliverables
are?
I
think
that's
pretty
clear.
Actually
anybody
want
to
home
that
they
don't
understand
the
deliverables
No.