►
From YouTube: IETF105-DISPATCH-20190722-1810
Description
DISPATCH meeting session at IETF105
2019/07/22 1810
https://datatracker.ietf.org/meeting/105/proceedings/
A
C
D
C
Here's
the
note-
well,
you
probably
would
have
seen
this
more
than
once
today
this
backwards
and
okay.
Here
we
go
so
we
actually
have
very
few
things
on
dispatch.
This
time
we
have
web
transport
Victor's
going
to
talk
about
that,
and
then
we
have
several
things
in
the
art
area
that
we're
going
to
talk
about.
There's
a
new
proposal
called
rip
and
then
we're
going
to
talk
about
this
will
be
a
fun
discussion.
The
BCP
190
I
put
the
ability
to
trance
okay
dispatch.
C
Okay,
so
as
a
reminder
here
are
our
IHF
106
deadlines
and
again
we
drive
those.
So
hopefully
there's
a
little
bit
of
mailing
list
discussion
before
people
before
the
meeting
right.
So
my
deadline
is
October
4th,
October
7th,
it's
always
a
good
just
to
let
us
know
that
you're
gonna
bring
something
forward,
so
we
can
play
on
time
because,
as
you
notice,
we
only
got
an
hour
slot
this
time,
because
we
didn't
anticipate
much
and
of
course,
at
the
last
minute
stuff
came
in.
C
So
it's
always
helpful
to
let
us
know
ahead
of
time
all
righty,
okay,
again
working
with
deadlines.
If
you
make
the
deadlines
you're
from
the
list,
if
you're
not,
then
you
kind
of
come
towards
you
know
if
time
allows
sort
of
thing
and
again
it's
helpful.
If
you've
got
a
dispatch
item,
you
want
us
to
dispatch
to
put
dispatch
in
the
name.
It's
a
little
bit
easier
to
find
in
the
tracker
and
there
is
a
way
again.
There
was
a
ticket
open.
A
A
Is
this
better?
Alright
I
picked
her
a
silly
if
I
worked
on
TLS
and
quits
I
want
to
talk
about
web
Transport,
which
is
the
new
work.
I
want
to
bring
to
ITF.
That
is
currently
already
a
consideration
and
w3c
web
and
compassion
community
group
so
just
to
introduce
you
to
the
problem.
So
web
applications
traditionally
used
only
HTTP
is
a
transport.
Http
is
a
response.
Request.
Protocol
means
that
you
will
only
get
traffic
from
server
if
you
send
a
request.
A
First,
around
2010
people
realize
this
as
a
problem,
so
we
introduced
a
protocol
called
WebSocket
which
allows
to
speak
subject
to
security
constraint,
arbitrary
TCP
traffic,
but
it
runs
over
TCP,
so
it's
reliable,
ordered,
and
that
is
enough
for
some
applications,
but
not
for
others.
Around
some
time
later
we
introduced
the
new
API
called
rtcdatachannel,
which
is
a
peer-to-peer
DTLS
over
HTTP,
and
it
has
a
API
which
is
very
similar
to
WebSockets,
except
your
messages
can
be
more
sent
and
received
out
of
order
or
marked
as
unreliable
in
general.
A
Rtcdatachannel
is
inherently
peer-to-peer,
which
means
you
need
it's
designed
to
communication
between
browsers
and
peers,
which
might
be
behind
net.
So
it
doesn't,
you
can
fit,
and
so
you
can
fit
it
inside
into
the
use
case
of
talking
client-to-server,
and
there
are
special
provisions
of
standards
called
I
slide,
which
is
a
way
to
use
data
channel
and
client-server
setting.
But
in
practice
it
doesn't
work
that
well
and
I've
had
conversations
with
many
developers
I'll
talk
later
but
which
doesn't
works
as
well.
A
A
Why
would
you
want
something
like
this
and
the
answer
is
for
many
years
people
have
been
asking
browser
developers
to
add
some
things:
that's
roughly
like
WebSockets,
but
for
UDP,
it's
being
a
repeated
request
and
we've
reached
out
to
some
of
those
people,
and
there
are
wide
variety
of
use
case
where
you'd
want
set.
But
the
two
main
use
cases
is
one.
A
There
are
lots
of
people
who
want
this
for
online
video
games,
because
video
games
traditionally
our
latency
sensitive
in
the
second
wide
use
cases.
People
really
want
this
for
live
streaming,
especially
live
streaming
with
low
latency,
and
the
proposal
we
have
is
called
web
transport
web
transport.
Is
it's
not
a
one
protocol,
but
it's
a
framework
for
making
protocols
which
are
usable
on
the
web
and
you
can
use
them
interchangeably.
A
So
the
idea
is,
if
you
have
a
transport
protocol
which
provides
strings
and
data
grams
streams
by
streams,
a
million
streams
which
are
like
quick
streams
or
like
an
individual
TCP
connection
or
their
streams
of
bytes,
potentially
bi-directional
or
Union
directional
and
datagrams.
When
I
say
data
rounds,
I
mean
saints,
which
are
shaped
like
UDP
datagrams,
but
in
order
to
become
be
compatible
with
web
transports,
the
Transfer
Protocol
has
to
be
subject
to
multiple
security
constraints
which
are
outlined
in
the
draft,
but
notably
your
transport
has
to
be
an
to
end
encrypted.
A
You
have
to
support
TRS
I,
you
have
to
support
Origin
Jack's,
and
you
have
to
make
sure
continuously
that
your
protocol
is
that
your
server
is
still
willing
to
talk
to
you,
and
so
sir
requirements
will
be
familiar
especially
to
those
who
work
with
data
channels,
because
those
are
essentially
similar,
very
similar
requirements.
So
when
I
say
protocol
framework
originally
this
was
the
one
protocol
called
quick
transport.
A
Not
eventually,
people
brought
ABS.
That
quick
is
not
always
usable
and
it
would
be
really
bad
for
us
to
just
fail
hard
if
quick
is
blocked
in
the
network.
So
we
defined
a
family
of
protocols
which
are
usable
interchangeably
and
the
one
of
them
is
called
quick.
Transferred
and
quick.
Transport
is
very
similar
to
WebSocket
I'll
talk
about
differences,
but
quick
transport
is
basically
WebSocket
over
quick
fallback.
Transport
is
a
simulation
of
that
semantics,
but
over
TCP
for
cases
when
quic
is
blocked
and
HTTP
free
transport
is
a
probably
most
interesting
here
and
most
complex.
A
Even
on
top
of
WebSocket.
We
do
bring
a
lot
of
improvements
which
are
just
not
just
like
the
obvious
improvement
of
unreliable
on
order
delivery.
For
instance,
we
you
no
longer
have
the
WebSocket
masking
protocol,
which
was
added
for
plain
text
WebSockets,
and
we
don't
have
to
use
it
because
we
encrypt
all
traffic
by
default.
H
If
you're
doing
TLS,
as
opposed
to
quick
as
your
underlying
substrate,
then
and
you're,
using
a
stream
cipher
like
RC
for
GCM
and
the
attacker,
can
produce
essentially
any
bit
pattern,
he
wants
in
the
wire
by
by
simply
X
by
X,
holding
the
keys
from
one
side
together
and
then
producing
producing
counter
masking
or
flipped
plaintext.
So
if
you
said
to,
if
you
think
this
is
a
problem,
it
is
still
potentially
a
problem.
A
H
A
The
other
saying
is
that
WebSockets
involve
a
special
shaman
base,
handshaking
headers,
and
we
use
the
that
then
quick
enforcing
al
Pianist
mandatory.
So
we
rely
on
LPN
to
avoid
cross
protocol
attacks
and,
as
our
improvement
is
unlike
WebSockets,
we
do
not
chip
cookies
or
any
credentials
by
default
and
assumes
that
the
application
has
to
communicate
this
explicitly,
which
I
believe
is
it
a
good
improvement
of
the
privacy
and
security
surface
of
the
protocol?
A
C
I
Repair
to
pay
on
Facebook,
so
if
we
want
to
do
these
things
for
a
real-time
communication,
often
that
means
skipping
past
something
that
has
consumed
some
part
of
the
offset
space,
because
it's
no
longer
relevant
to
the
application
so
being
able
to
read
things
piecemeal
or
at
least
being
able
to
bias
towards
the
most
recent
data
is
an
important
aspect
Thanks.
So.
J
Modern
Thompson
I'm
tentatively
supportive
of
of
this.
This
notion
I
do
recognize
that
the
sort
of
space
of
partial
reliability
or
unreliable
transport
from
a
client-server
perspective
is
really
really
awkward
when
you,
when
you're
forced
used,
WebRTC
and
there's
some
opportunities
here
to
to
use
quick,
more
providing
for
backs
to
HTTP
and
web
servers
and
all
those
sorts
of
other
things
that
we
have.
There's
a
bunch
of
complexity
here
with
respect
to
getting
the
api's
right
so
that
that
works.
J
J
J
Is
yeah
I
did
want
to
add
to
echos
point,
though
it's
not
just
to
TCP
that
suffers
with
it
from
this
problem.
If
you
were
able
to
know
the
keys
and
absent
some
difficulty
with
getting
the
packetization
right,
you
could
predict
the
ciphertext
of
something
and
therefore
influence
the
ciphertext
of
something
you
could
make
a
UDP
packet.
Look
a
lot
like
a
DNS
packet
and
there's
a
bunch
of
networks
out
there
that
look
at
their
nest,
packets
and
produce
responses.
I,
don't
know
what
you
do
that
with
that,
but
it's
just
food
for
thought.
K
Justin
Uberti
Google,
this
sort
of
speaking
from
the
rqc
standpoint,
I
think
you
could
probably
make
all
the
stuff
work
with
data
channels,
but
we
are
definitely
hearing
the
same
thing
that
it's
just
really
really
difficult.
People
are
having
a
hand
roll
their
server
stacks.
If
we
had
had
quick
available
to
us,
doulton
GTI
one
three,
you
know
eight
years
ago,
maybe
minder
made
some
different
choices.
I
think
this
can
be
really
useful
and
people
will
flock
to
it.
L
L
L
A
Are
so
quick
transporter
cars,
some
wire
changes
for
like
stuff
like
origin
checks,
but
those
are
relatively
simple:
HTTP
free
transport
requires,
like
some
sayings
to
fit
or
Batory
data
in
to
http
free
and
those
have
to
be
well
defined.
So
that's
that's
the
wire
part,
and
this
is
a
major
part
of
why
we're
bringing
it
here.
If,
because,
if
it
was
just
simply
an
API,
we
could
have,
it
would
have
been
to
some
extent
out
of
scope
of
IETF,
but
this
requires
a
lot
of
work
on
how
to
figure
out
the
wire
protocol
yeah.
A
L
C
L
M
N
C
C
E
Agent,
33,
trans
Lord
and
a
quick
transport
are
they
equivalently
secure?
It
seems
linearly.
Http
3
version
can
inherit
some
of
the
things
from
web
sockets
courts.
All
that
stuff
is
there
and
also
potentially
fall
back
with
the
issues
that
echo
readies,
the
potentially
their
the
quick
transport
just
uses
an
IP
address
and
a
port
doesn't
need
I,
guess
much
in
the
way
of
protocol
work,
but
from
a
security
point
of
view.
Could
you
comment
on
that?
Is
there
differences
in
the
security
requirements
and
function
now?
Also
the
functionality
seems
pretty
similar
right.
A
Basically,
yeah
in
terms
of
security
requirements,
I
believe
like
they're.
Both
there
are
slightly
different
strata
models,
but
with
HTTP
free
transfer
you
have
to
watch
out
for
like
once,
you
are
allowed
to
create
streams
within
a
connection.
You
have
to
make
sure
that
you
do
not
create
too
many
streams
and
within
an
eat
up
all
the
flow
control
window
from
regular
HTTP
traffic
but
others,
and
that
they
all
have
required
plenty
of
obtain
on
both
parties
side.
So
I
believe
it
should
be
safe
from
that
perspective,
as
they
both
require.
Tls.
A
E
A
P
Colin
jegs,
my
comment
is
actually
sure:
I,
don't
know
whether
this
is
exactly
the
right
solution
or
not,
or
what
the
technical
security
deals
are,
but
I
think
I
have
a
real
need
for
something
like
this,
and
it
would
be
really
useful
to
be
able
to
do
this
and
using
the
whole
web
RTC
data
channel
stack
is
is
just
into
it
is
too
difficult.
It's
a
bar
too
high
to
reach,
so
we
need
something
much
simpler
than
that
that
allows
us
to
do
it
I
think
we
proceed
with
something
along
these
lines.
Q
That's
ready
to
talk
about
the
dispatched
question.
I
think
this
is
a
big
enough
piece
of
work,
that
it
needs
a
pause
and
a
working
group
rather
than
being
assigned
to
an
existing
working
group
or
otherwise
dispatched.
Certainly,
I,
don't
think
it's
ready
for
a
tea
sponsorship
and
I
will
we
go
for
those
of
you
who
have
very
very
long
memories
that
when
quick
was
started,
one
of
the
things
inside
cool
that
was
considered
was
just
taking
the
WebRTC
data
channels
back
and
just
making
that
real
easy.
You
can
see,
we
didn't
go
there.
Q
We
went
somewhere
else
entirely
and
I
think
we're
at
the
risk
of
kind
of
coming
back
and
making
some
of
the
same
mistakes.
We
made
an
RTC
web
for
example,
though
the
WebSockets
API
imitation
again,
if
we
don't
start
with
saying
at
above
here,
are
the
requirements
that
we're
trying
to
meet,
and
here
are
the
design
spaces
of
api's
than
I
want
and
I
think
that
we
may
end
up
saying
that
what
you
end
up
wanting
is
quick
with
some
of
the
data
channel
capabilities
built
into
quick
native
rather
than
HTTP,
3
or
WebSockets.
R
H
High
branch,
Ramo
+1
to
the
it
seems
like
there
needs
to
be
a
bar
for
this
and
actually
encouragement
to
put
that
together
for
Singapore
like
it
seems
like
it's
actually
pretty
good
shape
to
take
there.
I
did
have
another
I
got
in
line
because
I
hadn't
heard
Rana
speak
yet
and
say
the
word
taps.
So
when
I
want
to
say
the
word
taps,
the
war
taps
was
in
original.
A
H
We're
looking
so
I
like
I'd,
like
to
make
a
more
specific
sort
of
suggestion
here,
specifically
you're,
looking
at
basically
having
this.
This
web
transport
run
on
top
of
three
underlying
potential
transports,
which
have
somewhat
different
contracts.
One
of
the
big
differences
between
them
is,
some
of
them
are
streamed,
and
some
of
them
are
not.
H
This
is
exactly
sort
of
the
kind
of
situation
that
the
Cape's
API
was
designed
to
look
at
I
would
suggest
having
a
look,
at
least
at
the
taps
architecture,
and
if
there's
anything
in
the
taps,
architecture
that
doesn't
cover
what
you're
trying
to
do.
We
would
very
much
like
to
know
about
it
in
taps,
because
we
want
to
finish
that
by
Singapore.
A
Yes,
so
so
short
to
answer
is
we
believe
that
it
would
be
useful
to
provide
the
taps
like
app
ability
in
that
JPI
for
this?
Yes,
we
do
not
want
to
actually
bake
it
like
on
zero
browser
API,
because
it's
kind
of
too
low
high
level
compared
to
what
we
want.
That's
a
short
answer,
but
we've
definitely
considered-
and
this
is
something
I
wrote
up.
Let's.
A
S
S
They've
found
a
lot
of
difficulty
in
using
web
proxies
a
web
RTC
to
build
peer-to-peer
systems,
and
hence
the
need
for
things
like
Beeker
browser
to
be
able
to
actually
add
application
level
like
explicitly
implement
protocols
like
that
in
the
browser
because
of
a
lack
of
more
protocols
like
this.
So
I
just
want
to
say
like
as
someone
representing
all
of
the
folks
that
I
talked
to
on
the
weekend,
there's
a
lot
of
demand
for
more
ways
that
we
can
do
networking
so
generally
support
it.
Cool.
B
H
To
quick
technical
points
and
then
all
next
I
guess
one
I'm
sort
of
cautiously
optimistic
about
this
I'm
vaguely
sad
that
people
seem
so
sad
about
data
channels,
but
visit
of
life.
So
there
we
are
I'm
I,
don't
think
this
will
solve
your
debt
problem
because
there's
a
specific
client
server
mechanism,
and
so
unfortunately,
your
continue
to
be
sad
by
digital's
in
terms
of
we
do
next.
This
is
clearly
like
way
way
too
big
to
just
a
tea
sponsor
or
take
to
a
poop
down.
T
A
R
A
U
I
Repair
to
pay
on
I
remember
this
time.
I
just
wanted
to
really
quickly
say
that
I
really
dislike
the
idea
of
quick
transport,
because
I
like
the
idea
of
having
one
protocol
that
I
can
dispatch
age-3,
for
instance,
because
people
have
said.
Is
that
the
same?
Well?
Yes,
but
it's
also
a
superset,
because
HTTP
implies
caching
and
caching
is.
A
A
Short
answer
is
I've
thought
a
lot
about
quick
transfers
versus
H,
Freight
transferred
and
I've
talked
to
a
lot
of
people
and,
depending
on
what
you
want
to
use
it,
for
you
will
either
really
want
one
or
other,
because
quick
transport
is
useful,
for
example,
online
games
which
just
do
exchange
real
time
staff,
and
they
don't
want
to
all
aged
free
overhead.
But
you
will
obviously
want
h
free
transport
to
understand
why
I.
B
J
Mike,
if
burthen
after
martin
mountain
thompson
in
terms
of
dispatching
this
they
the
w3c,
is
obviously
gonna
have
to
build
an
API
in
order
to
support
this
I
suggest
that
we
simply
respond
to
a
request
from
them
and
then
talk
about
creating
a
working
group.
In
that
context,
now
might
mean
that
we
wait
to
have
the
buff
until
they
make
their
decision,
but
it
might
also
mean
that
we
can
skip
the
buffing
part.
N
A
W
C
C
So
how
did
okay?
Oh
okay?
Sorry
about
that
someone
messed
up,
probably
me
and
then
there's
the
ad
Bob
applications
doing
DNS
I
didn't
put
when
that
one
was
down,
so
people
can
look
at
their
agenda
side
meetings.
There
is
a
side
meeting
and
Eric
I,
don't
know
if
you
want
to
say
something
really
fast
for
international
shaking,
because
I
just
went
through
and
looked
at
side
meetings
and
looked
at
once.
It
might
be
interesting
because
that
people
don't
say
if
they're
closed
or
general
interest.
O
I
Eric
Berger,
and
this
is
the
ITF,
so
we're
using
an
ITF
room.
So
it's
open.
However,
it's
mostly
going
to
be
regulators
and
policy
makers
from
various
countries
around
the
world.
So
if
you're
thinking
this
is
where
Jim
and
I
are
gonna,
do
a
knock-down
drag-out
steel
cage
match
of
international
shake
and
you'll
be
disappointed,
but
if
you're
interested
in
other
countries
other
than
the
US
and
Canada
adopting,
stir
and
shake
and
then
feel
free
to
come,
although
the
room
I
think
only
seats,
16
I
didn't
expect
lots
and
lots
of
people
the
show.
C
And
it's
the
color
room,
I
think
it's
Kohler
and
not
Collier
awesome
right.
There
earn
the
cold
line.
Okay,
alrighty
and
then
Victor
already
mentioned
his
his
web
transport
had
a
question
after
it
because
it
had
a
question
in
the
agenda,
but
it
sounds
like
you're
having
it
you're
on
right:
okay,
yep,
it's
on
and
then
there's
an
HTTP
priorities
thing
in
Van,
Horn
and
again
I
just
pull
things
that
look
like
they
might
be
interesting,
so
so
months
to
say,
30
seconds
on
what
that's
about
mr.
J
B
J
C
D
G
X
You
may
remember
that
you're
working
on
encryption
for
email,
so
that
users
can
actually
use
it
and
there
was
a
mailing
list
called
meetup
and
we
all
now
also
having
site
meetings
on
the
topic
and
the
next
time
meeting
will
be
on
Wednesday
afternoon.
I
think
it
was
free
20
in
the
room
up
there
in-situ.
C
C
N
G
G
We
before
we
get
into
the
topics,
there's
just
one
thing
that
I
wanted
to
say
and
I
don't
know:
Adam
wants
to
say
something
as
well.
This
is
Barry
liebe
Hart
ad
with
the
the
adsr
currently
have
currently
asked
the
NomCom
to
fill
two-part
ad
positions,
because
adam
and
alexei
are
ending
their
terms
at
this
time,
but
we
are
having
a
meeting
later
this
week,
the
art
ADEs
about
deciding
whether
we
really
want
to
fill
two
art
ad
positions,
or
just
one
and
drop
down
to
two
80s
in
the
area.
G
K
P
Okay,
I'm
going
to
be
talking
about
this
or
rip
stuff
here
for
a
second,
so
next
slide,
please
I!
Where
we're
at
a
very
early
stage
on
this
draft.
Okay,
the
authors,
don't
even
agree
on
what
to
do
we're
still
sort
of
thinking
about
it.
Much
of
the
stuff
that
I
see
coming
up
that
we
discussed
earlier
today
and
some
of
the
other
sessions
they
just
make
me
rethink
that
there's
much
better
ways
to
do
some
of
the
things
they're
in
here.
So
this
is
I.
P
Want
you
to
get
a
feeling
for
the
problem,
we're
trying
to
solve
and
we're
trying
to
get
a
bunch
of
people
to
come
and
get
their
input,
make
sure.
We've
got
a
variety
of
riot
requirements
into
it
and
it
meets
an
interesting
solution
and
it
is
around
the
space
of
sending
media
in
a
more
cloud
friendly
way.
P
So
next
slide,
please
the
problem
that
we've
been
looking
at
is
we
start
building
all
of
these
cloud
services
and
they
might
have
WebRTC
coming
up
with
them
and
they
typically
needed
to
take
a
sip
trunk
of
some
form
to
take
some
voice
over
to
the
PSTN
or
maybe
over
or
to
a
you
know,
voice,
recognition,
API
or
Texas
speech.
Very
there's
a
bunch
of
use
case,
we'll
talk
about
those
in
a
minute,
but
sip
was
not
very
friendly
in
the
way
that
it
worked
in
coming
into
large
current
cloud
deployments.
P
How
can
we
do
a
better
job
of
that
make
it
easier
for
us
make
it
easier
for
that
type
of
connection
to
work
so
we're
we're
looking
at
this,
is
you
know
if
you
take
WebEx
going
to
or
you
know,
I've
got
cloud
conferencing
service,
you
know,
there's
there's,
there's
end
users
and
the
devices
that
might
be
using
WebRTC
or
something
like
that
up
to
a
cloud
service
or
who
knows
what
they're,
using
it's
a
cloud
service,
that's
doing
a
bunch
of
processing.
It
inevitably
has
to
do
some
subtracted
a
off
to
a
service
provider.
P
That'll
connect
it
up
to
the
PSTN
and
what
we're
looking
at
is
replacing
that
link
at
the
top
one
on
the
green
here
between
the
cloud
service
and
the
service
provider.
It's
not
about
what
go
down
to
the
endpoints
or
any
of
those
things.
It's
a
cloud-to-cloud
sort
of
thing.
That's
you
know
less
than
20
years
old,
it's
a
sort
of
modernized
version
of
it.
So
next
slide
so
later
on
I'm,
going
to
talk
a
little
bit
about
the
technical
properties
of
this
hour,
but
we're
gonna
run
media
over
HTTP.
P
We've
had
several
discussions
about
that
in
various
forms,
day
of
h3
and
we're
going
to
try
and
have
a
very
simple
replacement
that
gets
rid
of
many
of
the
problems
that
we've
had
with
sip
SDP
and
RTP,
and
there's
a
lot
of
reasons
we
want
to
do
this.
A
the
big
ones
are.
There
are
all
kinds
of
services
that
were
built
for
scaling.
Large-Scale
websites
are
already
out
there,
they're
very
easy
to
use
you're
familiar
with
them.
You've
used
them
like
auto
scaling,
I
mean
load.
P
Balancing
is
something
that
you
can
do
and
sip
you
could
build
all
of
this.
Every
one
of
these
things
you
could
build
and
sip,
but
they're
already
built
as
deployed
an
incredibly
scalable
way
on
every
major
cloud
service.
I,
you
know
H
a
we
did
it
one
way
doing
assuming
a
certain
sort
of
design
and
sip
it's
very
hard
to
do.
I.
You
know
high
availability
in
a
modern
cloud
world
where
various
idioms
will
just
be
rebooted
and
things
like
that
as
part
of
the
surface.
P
It
wasn't
you
know,
sip
wasn't
designed
quite
for
that
type
of
high
reliability
was
designed
for
a
different
type,
so
API
gateways
being
able
to
use
those
being
able
to
use
all
the
modern
web.
Das
prevention
tools
service
meshes
all
the
application
monitoring
there
there's
just
an
incredible
amount
of
infrastructure.
That's
been
made
for
building
these
HTTP
based
services
and
we
want
to
be
able
to
take
advantage
of
those
in
a
really
easy
way.
So
that's
where
this
that's
the
design
space
that
we're
trying
to
deal
with
next
slide,
as
I
mentioned.
P
You
know
this
is
this
is
a
logical
extension
of
people
starting
to
move.
You
know
we
went
into
the
WebRTC
stuff.
This
moves
the
other
chunk
of
it.
That
was
never
what
was
always
out
of
scope
for
WebRTC,
which
was
how
do
you
do
those
cross
cloud
links
next
slide,
so
I'm
going
to
talk
about
a
couple
of
the
actual
sort
of
use
cases
that
are
the
drivings?
Yes
next
class,
please!
P
So
you
know
one
is
the
general
telecom
apps
and
bringing
those
into
like
a
wet
past
type
environment,
so
we're
seeing
more
and
more
of
those
you
see.
Companies
like
twill
others,
Google,
there's
all
kinds
that
have
various
infrastructure
for
building
these
things
and
how
do
we
connect
them
together?
The
calling
surfacing
anything
you'll
call
call
centers
in
that
type
of
area.
P
Right
now
is
in
a
large
transition
from
being
premise-based
to
being
cloud-based
and
as
they
move
to
that,
they
want
to
be
able
to
use
that
so
the
leading
cloud
call
center
providers
are
also
trying
to
deal
with
that.
If
you're
trying
to
embed
those
into
your
website
have
a
website
that
has
easy
chat,
it's
very
common
to
see
WebRTC
used
for
that
now
to
talk
from
your
browser
or
your
device
up
to
the
cloud
service,
but
there's
not
a
good
way
to
get
those
cloud
services
down
to
the
other
parts
of
it.
P
Next
slide,
SIP
trunking,
just
basic
connecting
to
the
PSTN
you'll
see
you
might
not
think
that
that's
a
that's
a
huge
part,
but
I
mean
like
keep
in
mind.
That
is
the
profitable
part
of
Skype
right.
That
is,
you
know,
a
key
part
of
every,
whether
it's
hangouts
or
WebEx,
or
any
of
these
call
centers.
It's
a
very
important
part
of
all
these
systems
is
connectivity
to
that
system.
Even
though
people
are
largely
IP
based,
they
still
need
the
option
to
be
able
to
do
that
for
a
certain
percentage
of
their
calls.
P
It's
a
very
painful
part
of
doing
it
next
slide.
So
I'm
gonna
jump
in
to
give
you
a
little
bit
of
flavor
of
the
way
we're
thinking
about
this
problem.
This
is
obviously
very
early
and
would
change
wildly
and
where
we
ghost
next
slide,
the
general
information
flows.
You
start
thinking
about
what
needs
to
go
from
one
cloud
to
the
other
cloud:
it's
really
not
very
much
information
and
it's
pretty
simple
in
these
cases,
largely
because
they're
constrained
and
we're
trying
to
currently
constrain
to
just
voice
on
PSTN
Interop.
P
We
expand
out
beyond
voice
later,
so
one
thing
that
you
need
to
know
is
hey
what
codecs
and
parameters
does
this
other
side
support
and
it's
a
very
static
thing
you
can
get
from
the
service
provider.
We
support
the
following
things:
that's
it
it
doesn't
change
on
a
call
by
call
basis.
It
doesn't
change
on
the
day
by
day
basis,
it's
a
pretty
static
thing.
Next,
when
you
go
to
set
up
a
call,
you
can
say
set
up
a
call
like
of
this.
You
don't
need
an
offer.
P
Answer
like
like
just
just
ask
the
web
community
how
much
they
love
offer
answer,
and
it
says
yes
or
no
that's
how
things
work
on
the
web.
It's
very
simple
information,
one
you
could
set
up.
It's
just
use
this
codec
this
phone
number.
Perhaps
then
we
get
some
basic
events
back.
There
are
very
few
handful
events
that
are
any
interest
to
what's
happening
with
a
call.
You
know
it's,
it's
proceeding.
It's
ringing
its
ended.
It
failed
this.
It's
pretty
simple.
P
The
media
stuff
is
a
little
bit
more
and
then
we
need
the
media
back
and
forth
and
I
think
a
lot
of
the
sort
of
things
I
saw
in
mobs
today,
early
on
and
here
today
there
are
different
ways
to
do.
Media
we've
been
doing
it
with
the
most
brain-dead
technique.
That's
been
proven
to
work
for
a
long
time
is
multiple
long
poles
over
h3
and
I'll
talk
a
little
bit
about
that
later
next
slide.
P
The
capabilities
of
what
we
think
that
you
should
be
able
to
describe
is
really
the
code
actually
support
maximum
bit
rates
size
of
samples,
whether
you
need
to
force
to
use
constant
bitrate
or
not
a
few
other
little
things,
but
I'd
say
that
very
minimal
set.
When
we
went
through
everything
that
was
an
SDP
and
said
what
parts
of
it
do
you
actually
need
for
this
type
of
system?
This
is
pretty
much
it.
We
throw
it
in
a
JSON
document
like
a
JSON
record
and
call
it
a
day
next
advertisements.
P
What
we
do
numbered
call
call
our
idea
of
the
caller,
which
always
brings
collect
big
questions.
Next
slide
lag
here.
We're
gonna
use
passport
sounds
really
complicated.
It's
a
JSON
object
with
like
three
things
in
it.
You
know
who
you
called,
who
you're
calling
the
time
signed
next
slide
the
protocol
mappings
of
this
of
how
we
map
it
into
h3.
There's
just
you
know,
there's
some
various
API
calls
that
we
hit.
We
hit
a
few
to
get
the
things.
I've
talked
about
like
getting
the
capacity
creating
a
new
call.
P
Once
you
have
a
call,
you
can
basically
pull
for
the
events
and
you
basically
set
up
a
bunch
of
concurrent
transactions
for
the
forward
and
backwards
media
next
slide.
The
basic
media
approach
that
I
talk
to
is
you
at
the
beginning.
You
know:
do
a
bunch
of
posts
to
set
up
these
concurrent
transactions
for
the
media
and
when
the
other
side
wants
to
send
you
some
media
when
it
has
the
first
RTP
packet
along.
It
sends
that
to
you
over
the
connection
and
we
mark
that
connection
as
in
use.
P
Without
my
way
we
call
them,
and
until
that
is
act
it's
in
use
and
when
the
next
RTP
packet
arrives,
you
would
send
it
over
a
different
byway
until
it
was
actually
a
third
one
arrived,
the
previous
ones,
actor
reuse
it.
So
it's
a
very
simple
transaction.
It
has
a
knack
of
every
packet
there's
many
ways.
We
could
probably
do
better
than
this,
and
we
can
talk
about
how
we
want
to
hit
those.
E
Just
my
my
comment
is
I
think
it
would
be
interesting
to
explore
how
this
might
be
done
within
the
web
transport
trial,
which
actually
is
real
code
to
see
if
it
can
be
done
better
or
if
the
changes
are
needed
to
make
it
more
efficient.
But
this
is
exactly
the
kind
of
flow
that
was
was
thought
about.
There.
P
E
P
Yeah,
no
I'm,
fine,
that's
our
events.
One
more
slide
after
this
that
we've
go
with
the
security
is
a
really
easy
model.
With
this,
too,
it's
all
exactly
how
we
do
web
security
there's
no
special
encryption
for
the
media,
no
special,
anything,
it's
just
TLS,
but
one
way
we
off
with
a
token
the
clinton
the
other
way,
and
it
is
not
an
indian
security
model.
This
is
this-
is
a
from
the
cloud
provider
over
to
the
PSTN
provider.
Okay,
it's
not
trying
to
accomplish
that.
I
think
that's
pretty
much
one
more
slide.
R
N
Z
G
R
P
P
P
O
P
And
sixty
percent
of
the
time
it's
connected
through
a
not
sip
interface,
to
get
to
sip
on
the
other
side,
so
either
way,
I
don't
care.
What
I
want
to
do
is
not
think
about
the
SIP
I
want
to
think
about
the
web
stuff
and
not
have
to
deal
with
all
that
crap
I
don't
want
to
worry
about
whether
it's
called
void,
interconnected
voice,
mobile
or
PSTN
okay.
So
we
we're
working
this
on
github
super
welcome
comments
on
github
PRS.
Any
of
those
things
love
to
work
with
people
on
that.
AA
R
C
U
Some
quick
background.
The
purpose
of
certificate
transparency
is
to
publicly
log
all
issues,
TLS
certificates
at
the
point
of
issuance
for
the
most
part
such
that
anyone
can
audit
them
and
we
can
detect
miss
issuance.
The
696
is
the
original
one,
and
this
is
draft.
32
is
the
current
version
of
V
2
and
certificate
transparency.
U
But
one
of
the
inherent
designs
of
this
was
also
to
not
sort
of
kicked.
The
trusted
third
party
can
down
the
road
and
then
trust
CT
logs,
and
so
we
achieve
verifiability
through
a
set
of
by
limiting
CT
logs
to
a
limited
set
of
behaviors,
and
it's
a
non
goal
of
ours
to
add
flexibility
to
these
log
operators
in
such
a
way
that
could
be
gamified
to
sort
of
counteract
some
of
the
overall
goals
of
certificate.
Transparency.
U
And
so
getting
kind
of
right
into
this
I
want
to
talk
about
the
approach
that
we're
recommending
here
and
then
following
this
I
have
an
analysis
of
alternatives
so
that
we
can
really
get
have
that
conversation
draft
31
of
6960
of
this
before
we
try
to
accommodate
BCD
190
with
the
well-known
language.
It
basically
specifies
this
that
the
log
server
prefix,
which
is
one
of
of
a
set
of
log
parameters
that
includes
log
key
maximum,
merge
delay.
U
A
couple
of
the
parameters
for
a
CT
log
is
specified
and
it
may
include
a
path
as
well
as
a
server
name
and
a
port.
These
two
entries
here
are
just
examples
of
two
of
the
api's
that
are
defined
and
it's
log
server,
slash,
CTE,
slash,
be
to
submit
entry
and
so
to
this
to
just
sort
of
hone
in
the
point
that
log
server
has
some
flexibility
into
it.
These
are
three
world
real
world
examples
of
existing
logs.
We
have
a
digit
cert
log,
which
shows
column
slash
log.
U
K
U
One
of
the
other
ones
that
was
heavily
debated
was
the
use
of
directories,
but,
as
I
mentioned
in
one
of
the
previous
slides
weird,
he
were
keen
on
reducing
the
ability
for
log
operators
to
hide
miss
behaviors
through
shenanigans,
and
so
we
don't
want
to
give
log
upper
to
the
ability
to
sort
of
hide
this
issuance.
If
you
will,
through
behaviors,
like
constantly
changing
the
directories,
and
so
one
of
the
goals
is
to
to
fix
the
log
operator
behaviors
in
such
a
way
that
the
behavior
is
well
defined
and
is
verifiable
and
I
did.
U
What
is
stale,
what
is
fresh,
and,
lastly,
we
considered
URL
templates,
but
currently
this
would
require
a
significant
increase
in
client-side
implementation
logic
that
is
otherwise
completely
on
required
by
the
protocol.
We
have
deployed
696
to
the
original
version
of
CT
by
certificate
authorities,
law
of
operators
and
multiple
user
agents,
and
none
of
the
members
of
the
ecosystem
have
expressed
concerns
with
this
specification.
U
Lastly,
on
this
point
in
a
real
world
scenario,
using
URL
templates,
it
would
likely
ossify
the
entire
ecosystem,
with
ossify
on
the
exact
same
structure
we
currently
have-
and
we
pointed
to
a
an
example
of
where
this
actually
happened
with
weirds,
with
some
discussion
on
that
point-
and
this
is
just
some
backup-
and
this
was
scraped
together
by
some
people
in
the
trans
working
group-
about
various
protocols,
either
in
ITF
or
not
that
don't
follow
this
section
of
BCP
190.
So
I'd
like
to
open
for
discussion
on
this
point.
AB
So
my
perspective
on
this
I,
both
a
domain-
that's
kind
of
the
primary
concern
of
PCP
190-
is
don't
put
restrictions
on
domain
owners.
I
operate
a
CT
log
I'm,
also
a
consumer
of
CT
logs,
so
I
use
this
as
a
client
and
I've.
Also
just
worked
a
lot
with
HTTP
API
is
in
the
past,
and
so
from
my
perspective,
the
CT
API
is
defined
in
69-62
is
PI.
It's
been
zero
burden
and
I
think
it
makes
a
lot
of
sense
to
keep
the
same
approach
for
v2
and,
generally
speaking,
I
think
you
know.
AB
I
spent
some
time.
Looking
at
the
history
of
the
discussion
on
BCP
190,
which
some
of
you
probably
remember,
started
as
draft
nodding
him
get
off.
My
lawn
and
I
looked
at
some
of
the
motivating
examples
early
on
and
there's
three
main
things
it
prohibits,
you
know,
don't
add
query
parameters
to
try
URLs
and
the
motivating
example
for
this
at
the
time
was
the
URI
signing
draft,
where
you
would
take
a
URL
that
existed
and
append
some
query
parameters
with
like
a
signature
and
so
on,
and
that
you
know
does
this
transformation.
That
is
invasive.
AB
On
existing
URL,
so
you
know
fine
I
think
that's
totally
reasonable.
There's
also
things
you
have
collisions
with
paths,
so
PCP
190
says:
don't
specify
an
absolute
path
on
a
server.
Somebody
might
be
running
something
else
there
and
then
the
third
thing,
which
is
section
2.3,
which
is
what
we're
talking
about
here,
there's
even
if
the
server
operator
specifies
a
prefix
out-of-band
like
in
these
examples,
slash
log
or
slash
logs,
are
gone
2019.
Even
then
you,
as
a
protocol
designer
you
can't
say
within
that
space
it'll,
be
flashed
et
/bg
such
submit
entry.
AB
You
have
to
indirect
that
through
some
other
mechanism
and
the
other
perspective
I
have
on
this
is
as
a
co-author
on
acne,
which
ran
into
a
similar
objection
early
on,
and
we
decided
we
actually
went
through
also
a
couple
of
rounds
of
iteration
on
okay.
How
do
we
work
around
this
thing?
On
the
first
iteration
was
bad.
We
use
link
headers
that
didn't
actually
adequately
model
our
space
we
needed
to
change
kind
of
mid
protocol
and
we
adopted
the
directory
structure.
Actually
during
this
process
for
69-62
Biss
I
suggested.
AB
Let's
just
try
directories
again
and
when
Rob
tried
to
add
that
to
the
draft
he
realized
there's
actually
some
bugs
in
this,
and
he
filed
an
errata
against
Acme
that,
unfortunately,
due
to
deployed
behavior,
we
can
now
fix.
So
you
know,
basically
what
I've
seen
is
adding
these
unnecessary
in
directions
produces
bugs
and
has
like
a
lot
of
potential
to
produce
bugs
and
at
the
same
time
the
normal
and
accepted
practice
for
specifying
API
is
that
use
HTTP?
B
A
Oh
silly,
if
I
will
be
very
fast,
nobody
should
ever
be
forced
to
follow
DCP
190
a
section
to
point
free
if
it
doesn't
make
sense
in
context.
I
personally
believe
that,
like
it,
has
been
shown
two
slides
with
good
all
of
the
protocols
which
people
use
in
real
world
extremely
successfully
like
say,
gates,
protocol
which
did
not
follow
it
and
two
just
fine,
so
I
do
not
believe
we
should
add
extra
complexity
just
to
satisfy
those
requirements.
R
T
Think
this
and
the
antidote
to
this,
which
I
think
is
also
a
problem
that
will
apply
to
other
verifiable
protocols,
is
to
make
the
protocol
as
rigid
as
possible,
because
that
reduces
the
number
of
ways
analog
could
have
misbehave,
and
so,
while
it
may
be
appropriate
for
a
non
verifiable
protocol
and
to
have
to
follow,
be
CP.
190
I
think
that,
in
the
case
of
verifiable
protocols,
it's
important
for
the
security
of
those
protocols
to
have
to
give
the
protocol
designers
flexibility
in
in
locking
down
the
protocol
to
make
it
more
verifiable.
P
K
Sorry,
no,
if
I
give
me
more
country,
we
do
want
to
have
a
side
meeting
on
this.
So
if
this
week
there's
not
one
scheduled
yet
because
it
wasn't
clear
that
the
people
who
cared
about
this
were
necessarily
paying
attention,
and
so
we
want
to
make
certain
that,
after
this
discussion,
we
got
a
meeting
together
where
the
interested
parties
were
able
to
get
together
in
a
room
and
talk
about
this.