►
From YouTube: IETF107-DISPATCH-20200323-2200
Description
DISPATCH meeting session at IETF107
2020/03/23 2200
https://datatracker.ietf.org/meeting/107/proceedings
A
We
have
reached
the
appointed
hour
wherever
you
might
be.
Thank
you
for
joining
this.
Is
the
dispatch
working
group
for
IETF
107
you're
charged
for
this
ARB
and
Campbell
&
myself,
fine
pending?
Yes,
that
is
here
as
well,
so
it's
gonna
be
first
for
everybody
and,
as
we
like
to
say,
if
you're
in
the
wrong
room
go
find
the
right
room,
but
I
guess
that's
just
some
other
place
to
browse
on
the
internet.
B
A
But
we
have
a
jam-packed
agenda.
Thank
you.
Everyone
for
your
you
know
forbearance
as
we
figure
out
how
we're
gonna
do
this
over
an
audio
conference.
Call
so
sort
of
the
first
rule
of
business
here
is,
please
make
sure
you're
muted,
both
your
video
and
your
audio,
your
microphone
and
we're
going
to
make
sure
when
we
do
questions
and
comments
and
the
presentations
we're
gonna
make
sure
we
take
them
all
at
the
end,
because
there
isn't
probably
a
great
logistical
way
of
interrupting
things.
A
We
will
talk
a
little
bit
about
how
we're
gonna
manage
the
queue
as
we
go
on
during
this.
This
okay,
so
we've
been
given
from
the
Secretariat
and
from
the
ADEs
I
do
hear
someone's
background.
My
confi
can
make
sure
your
mics
muted.
That
would
be
good.
The
Vice
begin
from
the
ADEs
is
that
we
want
to
use
the
WebEx
chat
that
is
associated
with
this.
A
This
audio
call
for
the
purpose
of
managing
the
queue
only
so
the
usual
back
channel
and
discussion
of
what's
going
on,
should
remain
jabber
as
usual,
and
we
will
have
a
jabber
relay
doing
that
work
or,
of
course,
you
can
just
cut
out
the
middleman
as
it
were
and
place
yourself
in
the
queue
using
the
WebEx
chat.
Just
a
second
right.
The
blue
sheets
always
an
important
part.
A
They
are
on
the
ether
pad,
so
I
put
the
ether
pad
into
the
WebEx
chat,
and
it's
also
on
the
agenda,
and
so
everyone
who's
in
this
call
really
needs
to
load
up
that
ether
pad
and
go
to
the
bottom
of
your
pad
and
enable,
or
rather
indicate
that
you're
attending
this
meeting
in
your
affiliations.
Just
as
if
you
had
a
sheet
in
front
of
you,
the
nice
thing
is
now
you
don't
have
to
pass
it
to
the
person
next
to
you.
Okay,
so
thank
you
to
some
folks
helped
us
ahead
of
time.
A
Braun
and
gene
are
taking
minutes
for
our
meeting
and
he
Sam
is
gonna.
Do
the
jabber
relay
service
is
appreciated,
see
if
I
can
advance
slides
all
right?
We
talked
a
lot
a
lot
of
this.
We
can
talk
about
the
WebEx
chat
and
queue
management
means,
if
you
haven't
seen
this
yet
and
then
one
other
meeting
minutes
like
this
happened
before
us.
A
So
here
we
go.
It
does
feel
like
the
first
meeting
that
we
get.
Doesn't
it's
a
reminder
of
sort
of
the
IPR
processes
under
which
you
know
your
activities
take
place
at
all
IETF
activities,
whether
they
be
in
person,
meetings
are
on
the
meeting
bus
or
anything
like
that
before
you
speak,
is
or
write
or
contribute
in
any
of
those
sessions.
A
A
But
if
there's
any
objections
to
that,
I'm
open
the
floor
now
to
hear
those
and
the
authors
are
still
prepared
to
give
their
presentation
and
to
have
that
discussion.
If
people
think
that
would
be
useful.
Oh
just
sort
of
pause
here,
I'll
jump
into
the
queue
just
do
that
on
the
WebEx
tap
for
ten.
Perhaps
we
will
get
15
minutes
to
read
life
back,
we'll
just
give
it
to
you
as
time
allows
material
we'll
find
out
okay.
So
it
sounds
like
that
is:
okay,
no
objections
were
heard.
Does
anyone
else
have
any
other
agenda
batches?
A
C
A
D
B
Very
much
yeah,
as
you
know,
we've
been
having
some
questions
on
the
mailing
list
and,
of
course
our
prime
concern
is
so.
Were
you
looking
at
a
home
for
our
IETF
drafts
on
the
client,
ID
technology,
sort
of
a
two
factor
change
to
both
SMTP
and
IMAP
protocols,
but
one
of
the
things
that
was
evident
over
the
last
year
is
trying
to
find
a
home
for,
of
course,
our
client
ID,
and
where
these
discussions
should
be
made
and
a
lot
of
the
working
groups
did
not
encompass
fully
enough,
for
it
was
outside
of
their
charter.
B
So
I
expanded
pre.
Before
this
meeting,
we
kind
of
expanded
the
conversation
to
discuss
whether
the
right
vehicle
for
this
would
be
going
through
to
Scott
dispatch
and
talking
about
a
new
IETF
working
group
that
could
address
email,
security
issues
as
a
whole
and,
of
course
that
would
make
a
great
place
in
a
home
for
our
client
ID
technology
as
we
go
through
this
go
through
the
slides.
There
is
some
opportunities
for
us
to
discuss
this,
and
but
I
do
want
to
just
give
a
little
bit
of
a
quick
overview.
B
Most
of
the
stuff,
of
course,
is
known
to
everybody,
but
email
is
still
the
number
one
use
service
on
the
Internet.
However,
one
of
the
things
I
think
anybody
who's
in
the
space
is
aware
that
the
email
compromises
and
the
hacking
attacks
at
email
accounts,
as
is
that
at
an
all-time
high,
also
as
comported
out
you
know,
the
problem
is
that
there
is
no
current
working
group
with
a
mandate
wide
enough
to
discuss
it
in
the
general
sense
of
email
right
now.
B
Of
course,
some
of
the
reasons
that
are
complicating
email
security
is
data,
leaks,
have
reached
all-time
highs
and
a
lot
of
hackers
have
moved
away
from
their
standard
spamming
box
to
using
authentic
Asian
botnets,
because
the
value
in
a
compromised
email
account
as
never
being
bigger,
and
this
also
in
in
the
world.
Today
we
have
a
situation
where
still
a
large
percentage
of
people
are
still
using
insecure
protocols
like
pop
and
SMTP,
sending
plaintext
authentication
over
in
clear-text.
B
This
is
a
huge
risk
to
companies
and
a
lot
of
both
customers
and
ISPs
either
still
are
not
conversant
enough
with
this
or
they're,
not
motivated
enough
to
actually
make
sure
that
those
insecure
technologies
are
not
being
used
and
especially
when
every
coffee
shop
router
seems
to
be
hacked.
Anything
in
plain
text
is
it's
not
about.
B
Maybe
that,
as
you
know,
as
the
IETF
do
we
have
some
responsibilities
to
actually
start
saying
that
popover
one
one,
zero,
plaintext
authentication
should
simply
not
be
in
our
documents
and,
of
course,
want
to
discuss
the
promoting
of
transparent
methods
of
security.
Like
our
client
ID
drafts,
you
know
whether
you
know
whether
the
ITF
has
a
role
in
in
helping
or
assisting
and
standardizing
those
things
next
slide,
please
so
I
guess.
B
The
first
thing
it
has
to
happen
is
that
the
dispatch
and
everybody
else
we
have
to
acknowledge
the
problem,
and
when
and
of
course
we
should
be
developing
a
take
away
problem
statement
in
order
to
determine
whether
a
group
is
you
know,
is
the
right
approach
to
addressing
these
situations.
You
know,
as
we
talk
about
email,
compromises
are
more
dangerous
than
ever
and,
of
course,
in
light
of
all
the
things
that
are
going
around
us,
we
understand
how
am
porta
now
email
is
becoming
again.
B
However,
when
an
email
account
is
compromised,
it's
a
lot
more
dangerous
than
it
used
to
be.
Nowadays,
the
hacker
is
a
lot
more
sophisticated.
They
do
everything
from
data.
Exfiltration
steal
your
personal
information,
all
your
contacts,
you
know
looking
for.
They
tend
to
own
your
mailbox
for
a
lot
longer
before
they
even
show
any
signs
that
they've
compromised.
It
gives
them
a
lot
of
tools
for
him.
B
For
instance,
you
know
personalized
spearfishing
of
the
ability
to
you
know,
impersonate
somebody
to
another
employee,
of
course,
to
pass
on
things
like
ransomware
or
we're
getting
the
CEO
to
transfer
their
money
and,
of
course,
if
they
access
your
email,
it
allows
email
is
technically
most
people's
second
factor
authentication
for
all
their
online
services.
So
when
you
want
to
change
a
password
for
your
banking
information
or
even
at
network
solutions,
if
you
want
to
transfer
a
domain
name,
you
know
you
can
do
the
password
resets.
B
You
know
without
the
customers,
knowledge
quietly
in
the
back
and,
of
course,
then
there's
the
actual
changing
of
existing
emails.
That's
possible
as
well.
I
think
we
all
recognize
the
top
three
methods
of
compromising
email
accounts
right
now.
A
lot
of
it
is
from
data
breaches.
Where
customers,
you
know,
I
mean
the
average,
the
average
ordinary
user
of
email.
Frankly
they
they
want
to
use
their
daughter's
name
and
they
want
to
use
that
their
daughter's
name
as
their
password
and
every
website
they
go
to.
They
want
an
easy,
an
easy
authentication
method
to
remember.
B
They
expect,
of
course,
the
data
providers
to
be
able
to
keep
them
secure.
However,
of
course,
when
LinkedIn
was
hacked
and
I'm
sure
that
some
of
us
are
still
seeing
the
hackers
attempting
to
brute
force
using
old,
leaked
information,
but
there's
also,
of
course,
you
know
the
plate.
The
second
one
is
the
plaintext
transmission
of
credentials
sniffing
they
compromised
the
IOT,
the
or
compromises.
B
All
of
these
have
create
an
easy
and
simple
way
for
the
hackers
to
you
know
to
be
able
to
find
active
email
accounts
that
can
easily
be
compromised
and,
of
course,
brute-force
attacks.
You
know
the
hackers
that
are
attempting
easy
to
guess
passwords.
In
some
cases
the
botnets
are
so
large
that
they
actually
second
do
some
targeted
brute
force,
using
all
data,
leaks
of
old
passwords
and
simply
adding
the
number
one
or
the
number
two
to
the
end
of
it.
Next
slide.
B
So
I
think,
what's
so
after
we've,
after
we've
done
that
we
have.
What
we
have
to
do
is
if
we
all
agree
that
this
is
a
serious
enough
problem
that
we
should
be
looking
at,
then
we
of
course,
have
to
develop
a
mandate
for
the
working
group,
and
you
know
one
of
the
things
some
of
the
suggestions
that
happen
on
the
mailing
list-
Priya's
conferences.
You
know
whether
we
should
actually
review
some
of
the
current
RFC's
that
encourage
your
support
or
allow
the
use
of
the
insecure
authentication
and
access
methods.
B
B
Then
the
other
there's
also
other
other
considerations
for
maybe
other
transparent,
two-factor
authentication
that
other
people
have
thought
of
or
that
are
easily
adoptable
at
the
community
and
transparent
to
the
end-user.
Maybe
client
ID
needs
to
be
modified
or
there
might
have
be
some
even
some
competing
options
and
what
are
the
other
mandates,
and
this
is
an
opportunity
for
us
to
get
feedback.
Several
members
talked
about
you
know,
would
this
potential
email
security
work?
B
You
know
a
seeing
if
we,
if
there's
something
to
do
about
addressing
the
sources-
I,
of
course,
some
trying
to
be
humble
and
and
see
that
there's
a
lot
more
intelligent
people
on
this
group
that
may
have
them
a
lot
of
other
ideas
and
I'd
like
to
sit
there
and
get
them
as
well.
Can
we
pass
the
next
slide.
B
Of
course,
one
of
the
obvious
questions:
why
aren't
the
any
of
the
existing
working
groups
suitable
for
this?
Well?
A
great
example
was
our
client
ID
RFC
drafts
I
mean
we
filed
these
things
already
a
couple
years
ago,
and
we've
been
trying
to
find
an
existing
working
group.
We
just
spent
an
awful
lot
of
time
discussing
it.
You
know
on
various
groups
whether
it
was
extra
art.
Some
people
were
talking
with.
B
B
B
Where
would
helpful
to
have
experience
from
other
members
of
the
community
who
aren't
actually
involved
in
real
world
implementations
and
understand
some
of
the
impediments
for
quick
adoption,
because
if
I
mean
we
can
invent
the
greatest
most
incredible
technology,
but
if
people
aren't
going
to
adopt
it,
I
think
we're
doing
disservice
to
the
community.
So
I'd
like
to
have
some
discussions
on
this
point,
and
but
if
anybody
else
has
any
ultra
of
suggestions
on
how
to
move
our
client
ID
or
discuss
these
topics
or
instead
of
a
working
group
by
all
means,
I
believe
that's.
B
You
sorry
I
was
so
quick,
two
slides
left
so,
but
one
of
the
you
know,
one
of
the
reasons
that
we
have
all
these
problems,
I
guess
is
a
lot
of
times-
is
without
the
mandate
of
the
IETF
RFC
SBC
P's
ISPs
have
really
no
motivation
to
change.
I'm
sure
we've
all
heard
it
from
somebody
who's.
The
CEO
says
you
know:
hey
I,
don't
want
to
change
the
way
we
do
things
I'm
worried
about
that
little
grandmother
up
the
hill
who
might
quit
our
service
or
there
are
other
people
that
say
well.
B
Are
the
RFC
say
that
we
can
still
do
this?
So
there's
no
reason
to
change
and
the
number
of
ISPs
is
still
allowing
it
or
just
you
know
our
do
us
a
disservice,
email,
clients.
If
you
take
a
look
at
the
majority
of
email
clients,
they
still
will
give
an
option
to,
of
course,
connect
to
these
pop
and
IMAP
and
SMTP
protocol
sending
clear
text.
We
need
to
have
send
a
clear
message
that
the
email
client
shouldn't
be
doing
that
any
more
customers.
B
You
know,
of
course,
don't
understand
this
and
they
don't
want
to
change
their
behavior.
We
want
to
sit
there
and
create
technologies
that
don't
require
the
customers
to
change,
how
everything
they
want.
They
don't
want
complex,
passwords
hardware,
dongles
anything
you
make
it
really
difficult
for
them
to
adopt,
they
simply
won't
use,
but
we
as
the
idea
you
know
as
members,
the
IETF
and
those
vendors
of
both
email,
clients
and
email
servers.
B
B
Sorry
I
have
to
email
one
of
the
things
as
I
will
post
the
actual
drafts
here,
but
I
didn't
think
it
was
right
to
actually
go
into
discussing
the
client
ID
drafts
themselves
in
fuller
detail,
but
we
can
of
course
explore
that
if
there's,
if
there's
interest
from
the
group
here,
I
just
wanted
to
point
out
that
one
of
the
reasons
that
we
started
off
with
this
client
ID,
you
know-
is
that
we
simply
it's
just
not
acceptable
to
send
a
dedication
over
unencrypted.
But
we
need
to
be
simple.
B
So
so
it's
the
technology
to
ask
the
change,
modern-day
pop-pop
and
SMTP
these
protocols.
You
know
they
have,
they
were
invented
for
a
different
world
and
we
still
haven't
yet
adapted
to
the
current
environment.
The
ability
to
limit
access,
authentication
attempts
to
individual
devices,
transparently
the
ability
for
a
server
administrator
to
be
able
to
say
I,
guess
just
like
in
the
old
blackberry
days
we're
only
this
100
devices
can
access
my
mail
server,
several
email
clients,
we've
already
have
them
supporting
client
ID.
B
They
were
real,
quick
to
understand
how
being
able
to
lock
a
mailbox
or
to
be
able
to
not
you
know.
Add
this
extra
level
of
security
is
something
that
needs
to
be
simple,
transparent
and,
of
course,
that
goes
to
show
how
easy
the
implementation
of
our
proposed
draft
are
several
other
server.
Vendors
are
interesting,
it
supporting
it
as
well,
but
it
does
require
a
change
to
the
actual
protocol,
so
what's
the
best
forum
or
mechanism
to
move
these
drafts
forward.
B
F
Try
and
be
quick
thanks.
I
agree
with
Michael
that
this
is
worth
the
working
group
we've
already
deprecated,
plaintext
authentication
but
I
think
I'm,
some
PC,
ps4,
PGP
or
two
for
mailed
or
for
mail.
End
users
I
think
making
it
clear
we're
talking
about
authentication
to
the
end-user.
This
is
not
server
to
server
stuff.
On
the
other
hand,.
D
F
Don't
think
much
of
the
client
ID
thing
is
just
another
password
to
steal
and
I
think
we
can
do
some
interesting
work
about
like
I
could
do
you
know
time-based
one-time
based
one-time
password
that
these
the
IMAP
client
could
automatically
send
so
it
you
know.
So
it's
not.
It's
not
popping
up
a
copy
request.
Every
time
you
check
your
mail
or
you
know,
or
six
times
a
session,
but
it
still
will
be
something
that
would
make
things
a
lot
more
secure.
So
it
basically
yes
to
working
group,
but
no
to
this
particular
draft.
G
Yeah
I
think
I'd
basically
agree
with
John
here
I
think
we
find
out
a
working
group,
but
this
mechanism
seems
not
amazing.
You
know
when
we
decided
to
do
two
FA
for
web.
We
decided
to
do
it
with
you
know:
digital
signatures
and
tied
to
the
connection,
as
opposed
to
a
bearer
token
which
what
this
is
the
extent
to
which
we're
concerned
about
people
using
plain
text.
B
I'd
like
to
respond
really
quick,
the
first
of
all,
of
course,
you
know
thanks
John,
we
were
respect
to
an
awful
lot,
but
of
course,
if
this
is
a
working
group
for
email
security,
it
would
be
the
right
place
to
actually
discuss
that.
I
think
we're
a
little
early
to
sit
there
and
expert
ick
Euler
draft.
G
Sure
so
either
your
theory
is
this.
Data
is
encrypted
or
your
30s
today
is
not
encrypted.
If
your
theory
is
David
is
people.
If
we're
going
to
mandate
encryption,
then
the
passwords
are
actually
pretty
good.
If
we're
gonna
mandate,
if
we're
thinking,
people
are
not
gonna
quit.
Thank
your
token
has
the
same
problem
so
I
think
you
need
to
separate
out
what
you
think
your.
What
you
think
your
solution
does.
B
Thank
you
again,
like
I
said,
I
mean
I
should
ask
the
dispatch
group,
but
I
did
you
know
I
didn't
know
if
we
were
going
to
delve
into
the
actual
into
that
our
drafts,
otherwise
I
probably
would
have
prepared
more
material.
I
thought
we
were
first
trying
to
discuss
where
the
best
place
to
have
those
discussions
is
as
part
of
the
match.
B
E
A
E
Further
say
that,
really
at
the
end
of
the
day,
what
dispatch
needs
to
know
is
the
problem?
Is
people
want
to
work
on
and
what
the
scope
of
that
problem
is
yeah?
Where
do
we
go
from
there?
If,
where
would
we
go
from
here
involved
a
mini
working
group?
Something
like
that,
then
we
would
need
to
come
up
with
a
charter
with
a
real
scope
is
easy,
and
maybe
these
drafts
or
input
into
that
and
maybe
they're.
Not
so
it's
reasonable
to
think
you
think
about
these
graphs
a
little
bit.
A
B
E
E
H
Thanks
really
I
want
I
agree
with
what
John
and
Ecker
was
Anthony
working
group
here
makes
sense.
I
am
concerned
right
now.
The
conversation
is
still
too
broad
and
I'm
worried
that
looking
at
the
top
three
methods
compromise,
the
email
accounts
is
also
sort
of
the
wrong
lens
here,
because
these
aren't
be
where
the
protocols
work
down.
They're,
not
all
in
one
place,
and-
and
some
of
these
are
a
tremendous
amount
of
work
to
address.
I
I
think
this.
This
requires
a
lot
more
discussion
on
exactly
where
to
focus.
H
I
also
think
the
client
ID
draft
is
the
wrong
place
to
start.
There
are
sort
of
two
things
that
that
jump
out
about
client
ID
in
particular.
The
first
one
is
that
the
that
credentials
just
equally
as
fortable
say,
an
ello
name,
which
is
used
for
sort
of
the
same
mechanism,
and
the
second
one
is
that
it's
it
feels
like.
You
need
a
pre-arranged
relationship
for
the
client.
They
do
to
make
sense,
and
the
whole
point
is
everything
we're
doing
and
email
series
to
get
rearranged
relationships
between
senders
and
receivers.
H
The
something
seems
very
weird,
with
this
draft,
and
so
all
that
said,
I
think
this
is
absolute
place
to
spend
time,
but
I
think
it's
got
to
be
focused
more
than
this
is
the
method
to
here
a
couple
of
really
specific
protocols.
Here's
one
very
specific
problem
that
we
should
tackle.
First
I'm,
not
sure
what
that
is
right
now,
but
I
think
that
that's
really
what
I
think
Michael
said
is
what
we
need
to
focus
on.
E
I
This
sounds
like
a
good,
durable
working
group,
but
not
these
things,
because
I
think,
if
you
drill
down
on
the
problem,
you're
actually
trying
to
solve
here,
you'll
form
a
charter
that
either
will
get
these
documents
into
the
working
group
or
we'll
have
a
good
set
of
reasons
for
yeah.
These
are
the
things
we're
looking
for,
but
not
these
particular
solutions.
I
B
Sorry
I
should
have
muted
well.
That
was
were
listening
to
you,
but
they
actually,
there
are
some
we've
already
made
some
statements
on
that
for
us.
It's
our
goal
to
have
the
whole
world
adopting
these
things.
We
think
it's
very
simple
and
having
worked
with
several
different
vendors
and
several
different
email
clients
and
helping
them
implement
it
quickly
and
easily.
B
I
K
J
Working
group
is
going
to
be
formed
here.
We
would
need
to
an
idea
of
what
problem
is
trying
to
solve
and
I
feel
like
there's
two
problems
that
came
out
from
the
presentation
here.
One
is
generally
getting
insecure
stuff
out
of
the
email
infrastructure
on
things
like
lack
of
encryption.
Things
like
on
authenticated
aspects
and
the
other
one
is
solving
phishing
and
the
count
take
over
both
solving
account
takeover
email
and,
generally
speaking,
kind
of
two-factor
or
multi
factor
for
email
access.
J
Now
one
of
those
seems
kind
of
doable
well,
so
the
first,
the
kind
of
general
better
advice
for
us
is
use
of
security
features.
An
email
seems
like
something
that
we
could
definitely
do
like
I.
Think
people
on
this
call
probably
a
pretty
good
idea
of
what's
good
and
what's
not
with
that
bucket,
unless
it's
less
clear
to
me
did
anyone
would
pay
attention
to
that.
Like
it's
been
pretty
clear
for
a
long
time,
what
the
good
stuff
want,
the
bad
stuff
is,
and
people
still
use
the
bad
stuff.
J
So
on
that
bucket,
like
it's
clearly
achievable,
Lockley
won't
have
much
value
in
the
end.
On
the
multi-factor
point,
I
think
there
probably
is
some
benefits
be
had,
but
it's
a
little
bit
more
of
a
science
project.
These
sort
of
standards
projects
often
work
best
when
there's
some
deployed
art
and
it's
been
widely
deployed
in
some
contexts
already.
J
B
Thanks
Richard
I
do
appreciate
you
sitting
there
realizing
that
the
mole
anything
that
was
how
is
gonna
help
on
the
multi-factor
is
really,
of
course,
the
goal
here.
When
we
talk
about
it's
the
plaintext
pass.
Sorry,
we
know
we
talk
about
the
plaintext.
That's
one
issue
we'd
like
to
see
the
ITF
tackle
that
for
us
personally,
of
course,
we're
more
interested
in
things
like
the
data
breaches.
The
brute
force
attacks
the
easy
to
guess
passwords,
where
you're
not
going
to
get
end
users
to
do
to
change
their
behavior.
B
However,
if
you
have
a
server
operator
and
an
email
client
that
both
agree
to
slightly
extend
the
protocols
by
you
by
the
way,
just
so
you're
aware,
you
know,
we
have
a
couple
million
people
in
North
America
that
now
I
have
client
ID
access.
They
we
have
just
recently
very
large
products
like
blue
mail,
sanebox
even
Thunderbird,
and
you
know
Lib
Batman,
and
so
there
is
already
getting
to
be
a
widespread
adoption
of
this
little
protocol
because
it's
so
simple
and
it
does
fix
a
pain.
B
Well,
I
believe
that
I'd,
of
course
volunteer
to
be
part
of
that
if
it
was
necessary
but
I.
You
know
I'd
like
to
sit
there
and
assume
that
email
security
is
a
large
enough
problem
that,
from
that
Widow
that
once
discussion
of
it
being
formed,
I
think
it
would
track
lots
of
very
influential
IETF
contributors
that
I
know
of
who
have
already
discussed
this
topic.
K
So
that
leads
to
my
second
question:
Stephen
Farrell
has
typed
to
jabber
about
like
five
times
or
something
like
that.
Asking
about
major
mail
carrier
interest
participation,
deployment
things
like
that.
I
think
that
you
are
making
a
pretty
compelling
case
that,
if
they're
not
interested,
they
ought
to
be
yeah
but
I.
Well,
I
did
want
to
go
ahead.
Make
sure
that
that
made
it
into
the
notes,
even
if
the
answer
is
yes
that
seemed
like
that
was
worth
recording.
Thank
you.
B
And
for
the
record,
there
is
discussions
ongoing
with
some
major
carriers.
I
would
sit
there
and
say
that
some
of
our
customers
are
mid-level
carriers
that
are
already
really
excited
about
it
and
I've
had
a
lot
of
people
that
are
looking
at
the
enterprise
space
that
are
also
quite
excited
about
this.
L
Hi
there
I
I
appreciate
the
simplicity
of
the
proposal,
but
I.
It
really
does
feel
like.
It
is
not
a
way
that
we
would
design
a
security
mechanism
today.
I
agree
that
we
do
need
to
be
thinking
about
the
impact
of
this
stuff
on
on
the
email,
ecosystem
and
I.
Think,
if
we're
going
to
design
something
that
offers
like
a
two-factor
authentication
that
mail
user
agents
could
implement,
we
can
do
better
than
this
today.
L
M
N
I
just
want
to
out
the
other
side
from
everything
I've
heard.
It
sounds
like
what
whether
people
would
be
in
favor
of
this
or
not
depends
highly
on
what
the
Turner
actually
said.
So
we've
already
heard
that
from
a
couple
of
people,
I
think
you
know
that's
where
I
land
as
well
I
need
to
see
a
charter
to
have
any
clue
whether
it
was
supported
or
not
thanks,
Buffy
and.
I
And
this
is
a
question
for
the
chairs
I
think:
is
it
appropriate
in
dispatch
for
him
to
post
a
couple
of
messages
on
here's
sort
of
mushy
that
I'd
like
to
work
on
and
and
some
ideas
about
what
the
problem
statement
is-
and
here
are
some
comments
by
folks
who
have
implemented
this
to
let
you
know
what's
going
on
or
does
he
need
a
new
mailing
list?
First,
I.
E
O
E
P
Maybe
he
will.
This
is
barri,
yes,
III!
Think
a
bit
more
discussion
of
this
on
dispatch
would
be
fine,
I
think.
If
we
go
more
than
a
little
bit,
we
should
have
another
mailing
list,
but
what
I'm
seeing
is
a
lot
of
support
for
talking
about
two-factor,
authentication
for
email
and
I?
Think
a
charter
that's
focused
around
that
would
be
great
and
I
would
encourage
a
few
people
to
get
together
and
start
putting
such
a
charter
together
and
Michael.
I
suggest
it
would
be
good
for
you
to
join
them.
F
Q
Just
wanted
to
say
that
whatever
we
do
here,
it
would
be
interesting
to
make
sure
it
works
well
with
J
map
as
well,
and
we
just
had
a
t-rex
or
spot
just
before
this
switch
was
talking
about
something
like
a
Wharf
but
doesn't
necessarily
need
to
have
a
web
browser.
It
seems
like
that
might
be
a
place.
That's
already
working
on
authentication.
B
B
The
last
gone
sorry
I,
think
Barry's,
comment
of
mailing
list,
I
think,
might
be
an
idea,
because
one
of
the
things
as
I'm
concerned
about
is
the
people
that
are
actually
involved
in
email
may
not
actually
be
part
of
this
dispatch.
Mailing
list
or
may
not
be
having
an
opportunity
to
have
a
voice
and
I
think
that
even
a
mailing
list
on
this
topic
might
be
an
excellent
first
steps
or
early
steps
so
that
we
can
engage
all
of
the
different
partners.
P
B
E
S
I
Yeah
I
think
a
buff
is
appropriate,
but
let's
not
let
that
Michael
and
others
from
working
on
some
sort
of
Chartres
statement
before
that
happens,
because
we
will
tend
to
push
things
out
and
the
BOP
shouldn't
be
the
first
time
we
see
a
you
know,
sort
of
collection,
of
what
the
problem
statement
is.
So
let's
do
the
problem
statement
and
then
think
about
when
we
set
up
a
bar.
In
my
opinion,.
P
Nor
do
I
yeah.
Basically
what
Pete
said
I
think
the
right
thing
to
do
is
I
guess
the
right
thing
to
do
now
is
somebody
make
a
non
non
working
group
mailing
list
request
to
me
and
I
will
create
it,
and
discussion
can
go
on
there,
for
what
I
would
like
to
see
is
people
starting
to
look
at
what
work
might
be
chartered
and
some
kind
of
draft
charter
proposal,
which
can
then
go
into
a
buff
at
108?
P
Q
P
A
A
Instead,
it's
the
list
with
the
distillation
of
you
know
how
we
understood
our
next
action
as
well
as
forming
this
mailing
list,
and
we
can
kind
of
go
from
there,
but
it
does
seem
like
the
next
steps,
are
gonna,
be
drafting
it
pretends
to
charter
and
determining
you
know
what
the
best
forum
for
that
charter
you
know
would
be
people
feel
about
it,
because
I
think
it's
clear.
We
need
to
understand
some
of
the
details
to
understand.
A
You
know
what
the
scope
with
a
working
group
would
be.
Really
some
folks
want
to
see
that.
Okay
with
that
being
said,
and
thank
you
for
the
meaningful
discussion-
and
we
are
actually
you
know-
because
we
we
agenda
bashed
here-
we're
actually
basically
on
time.
So
so
that's
going
well
we're
gonna
talk
transition
here
into
the
art
area,
meeting
portion
of
our
program,
so
dispatch
is
concluding.
Art
is
beginning
and
I
think
we'll
jump
right
into
the
UUID
presentation.
So
do
we
have
Brad
available.
U
U
Okay,
so
why
is
it
important?
Where
is
this?
Coming
from?
There
are
a
lot
of
database
systems
right
now
that
use
uu
IDs,
as
you
know,
primary
keys
and
other
keys
one
way
or
another,
its
existing
and
deployed-
and
you
know,
got
examples
of
that-
my
sequel,
Postgres
Cassandra-
they
all
have
some
some
level
of
they
are
using
you
IDs
in
one
way
or
another.
You
know
as
as
keys
and
they
work
fairly
well,
there's
they're!
Not.
U
There
are
a
lot
of
things
that
do
well
with
them,
but
there's
some
issues
that
kind
of
continually
crop
up
that
I've
run
into
that
other
people
run
into
so
yeah.
This
is
to
kind
of
outline
that,
and
the
idea
would
be,
that
we're
kind
of
going
on
the
assumption
here
that
it's
easier
to
make
some
small
incremental
changes
to
you
IDs,
as
opposed
to
coming
up
with
something
completely
new
and
different
in
trying
to
standardize
that
and
the
other
thing
is
that
databases
you
know
these
days.
U
You
know
the
United
specification
is
from
you
know
about
15
years
ago,
and
these
days
databases
are
a
lot
more
distributed.
So
the
old
you
know
auto
incrementing
primary
key
thing
is
less
and
less
workable,
and
so
they
find
a
lot
more
systems
are
saying.
Okay,
good
I
need
to
create
a
unique
identifier
and
insert
it
myself
instead
of
having
a
consensus
and
what
is
a
unique
identifier
across
a
large
cluster
of
machines
and
so
that
that
thought
process
tends
to
lead
to
the
use
of
UUID
as
a
key,
as
opposed
to
just
other
mechanisms.
U
Next
slide,
please
you
so,
okay,
so
a
couple
of
the
specific,
the
specific
issues
that
we
run
into
when
you
go
and
just
try
to
use
a
UID
as
key
for
versions
two
to
five,
the
there's
an
index
locality
issue,
which
is
essentially
boils
down
to.
If
you
insert
a
bunch
of
keys
into
a
into
a
binary
tree,
putting
them
at
the
end
tends
to
be
a
lot
more
efficient
because
you
don't
have
to
touch
all
the
various
different
pages
of
the
tree.
U
U
There
is
a
version,
one
UID,
that
is
time
ordered,
but
it's
there's
some
things
that
are
inconvenient
about
it
and
we'll
go
into
some
work,
but
the
sequence
of
the
bytes
makes
it
so
you
can't
easily
sort
it.
It
probably
would
not
be
worth
fixing
if
it
were
just
for
that
one
thing,
but
there's
some
other
issues
too,
so
the
the
thought
processes
will
adjust
that
at
the
same
time,
next
slide.
Please.
V
U
On
version
one
UUID,
so
those
have
a
timestamp
they
are,
they
are
time
ordered,
but
then
the
specification
as
it
stands
right
now
says:
okay,
we're
gonna,
go
and
put
the
MAC
address
of
the
machine
into
the
node
field
and
there's
various
that
that
can
be
an
issue.
It
can
be
a
security
issue
and
it
also
potentially
arguably
could
be
a
uniqueness
issue
depending
on
its
it's
open
for
debate,
because
more
and
more
machines
or
virtual
these
days
and
all
that
stuff
but-
and
we
can-
there
can
be
more
discussion
on
that.
U
If
that
part
is
in
question,
but
that's
the
part
of
version
one
year.you
ID,
that
makes
it
a
deal
breaker
is
this
thing
that
the
spec
says
use
a
MAC
address
were
a
lot.
You
know
the
last
thumb
whatever
it
is
last
six
bytes
of
that
of
that
value
and
another
issue
that
comes
up
is
text
format.
You
you,
IDs
are
very
long.
You
write
them
out
as
hex
with
dashes
like
that
and
that's
kind
of
just
impractical
for
a
lot
of
modern
applications.
U
If
we're
going
to
go
and
if
we
are
going
to
go
and
do
an
improvement
to
you
IDs,
it
will
be
great
to
see
a
text
format
that
is
more
generally
useful
and
so
I've
in
in
the
draft
that
that
was
put
together
on
it.
It's
got
a
base
62
and
it
basically
for
form
next
slide.
Please,
okay,
so
I
realize
it's
a
bit
dense,
I'll,
just
kind
of
cover
the
highlights,
but
yeah
yeah,
so
on
uniqueness
right
now,
again
the
the
specification.
U
What
ends
up
happening
is
the
specification
says
either
use
the
MAC
address
or
there's
several
different
mechanisms
for
hashing
and
really
those
are
the
source
of
the
uniqueness
right.
That's
that's
what
ends
up
actually
physically
happening
and
in
the
situation
where
we're
saying,
okay,
good
we're
gonna
implement
uu
IDs
as
a
key
in
a
database.
The
reality
is,
although
I
get,
the
name
is
universally
unique.
In
reality,
it's
only
as
unique
as
the
input
so
for
the
purpose
of
a
database
cluster.
U
U
It's
a
point
of
discussion,
but
right
now
the
detail,
the
there's
a
lot
of
detail
in
the
specification
that
says
you
need
to
generate
it
exactly
this
way
when
you
use
the
MAC
address
here
and
do
all
the
stuff
and-
and
it
implies,
if
you
don't
do
that,
then
what
you
have
is
wrong.
However,
in
in
reality
you
make
a
UID,
you
can
use
it
in
lots
of
places
and
as
long
as
it
physically
fits
some
basic
binary
requirements,
it
will
function
properly.
U
U
Yeah,
okay-
and
this
is
this-
is
a
little
more
detail.
I
think
we
can.
We
can
skip
that
one
I
pretty
much
covered
it
slide,
please,
okay,
good!
So
the
here's,
the
the
goal
of
the
draft
as
it's
been
put
together,
it
maintain
as
much
compatibility
as
possible.
So
there
were
some
other
things
when
I
was
first
looking
into
this,
and
and
in
discussions
with
various
people
was
like
okay.
Well
should
we
you
know,
maybe
you
can
have
variable
lengths
and
they
shouldn't
be
one
kind
of
128-bit.
U
You
know
those
those
are
interesting
ideas,
but
in
reality,
if
we
change
that
we're
changing
too
much,
that's
an
opinion,
but
that's
kind
of
in
some
of
the
discussion.
That's
also
where
that
when,
if
we
want
to
make
you
IDs
work,
has
kind
of
got
to
still
be
a
UUID
again
some
assumptions
there,
but
that's
the
idea
as
it
stands
now
they
would
be
the
proposal
as
time
warner
for
good
index
locality.
U
Yeah
and
this
point
about
figuring
out
in
the
specification:
what
should
it
say
about
what
is
acceptable
for
uniqueness
in
different
context,
and
is
it
okay
for
applications
to
just
decide
hey?
This
is
good
enough
for
my
application.
It's
binary
compatible
is
that
correct
per
the
spec
and
I
figured
while
we're
doing
all
this.
If
this,
you
know
if
this
gets
standardized
eventually,
then
mine
is
walking
and
all
the
sorting
so
that
it
sorts
directly
as
a
raw
bunch
of
bytes.
They
don't
see
any
value
in
preserving
an
additional
complication.
U
Whatever
again,
it's
my
opinion,
but
that's
that's
a
piece
of
information
there
and
then
also
on
the
text
format.
So
can
we
get
something
that's
more
more
useful
in
for
other
for
applications
in
general,
so
you
can
put
in
a
URL
something
you
can
have
typed
in
by
a
human
that
doesn't
need
as
much
length
to
it
that
sort
of
stuff
next
slide.
Please.
U
Good
and
I
think
this
was
just
more
detail
on
those
things.
Yeah
there
was
some.
This
is
basically
a
breakdown
of
the
bits
of
the
you
know.
What
exactly
we're
talking
about.
I
think
we
can
skip
that
I.
Think
we're
I,
think
that's
the
those
are
the
core
ideas
and
concepts
and
the
goal
and
the
the
you
know
from
my
perspective,
what
we'll
be
trying
to
achieve
at
this
moment
in
time
is
just
to
figure
out
where
the
discussion
would
go,
and
this
I
realize
there's
a
lot
of
things
that
could
be
argued
about.
U
This
there's
been
various
discussion
previously,
but
the
the
core
idea
is
people
are
using
new
IDs.
Now
we
could
do
a
better
job.
They're
using
for
databases,
I
mean,
and
we
could
do
a
better
job
of
you
know
improving
that,
so
that
it
works
well
for
that
scenario-
and
these
are
some
of
the
specific
points
that
that
go
into
that
and
I
would
like
to
just
nail
down
where,
where
could
that
be
discussed,
so
that
each
of
these
things
could
be
hashed
out
some
much?
What
I
have.
E
W
U
So
the
idea
would
be,
if
you're
inserting
it
into
a
as
if
you
have
it
as
a
database
key
then
it's
sequence
in
whatever
index.
That
is
so.
You
know,
if
you're
from
a
database
perspective,
if
you're
doing
a
select,
what
order
does
it
is
it
returned
in
and
just
defining
you
know
what
is
what
is
the
exact
for
each
ID
generated,
which
one
always
occurs
before
or
after
or
is
equivalent
to
to
another
value.
W
W
V
J
Hey
the
question
I
want
to
ask
here
is
why
we
need
a
specification
here
right
like
the
RFC,
is
defined
basically
interface
specifications
between
these
things,
and
it
seems
like
what
you
did
use
cases
you've
been
describing
so
far
are
basically
internal
to
a
database.
So
it's
not
clear
to
me
why
you
would
need
something
you
need
as
a
specification
for
this.
You
know
where
you
would
have
you
know,
intervention
intervention
or
something
and
needed
specifications
and
negotiate
that,
as
opposed
to
just
databases,
making
good
decisions.
U
So,
Dancer
that
there
is
some
you
know
anytime,
you
have
a
you
know,
column
in
the
database.
It's
gonna
end
up
getting
read.
You
know
by
some
piece
of
code
now
agreed.
There
is
definitely
a
certain
amount
of
like
it's
going
to
be
internal
to
the
database,
however,
that
that
value
is
going
to
need
to
get
transmitted
and
potentially
will
end
up
all
the
way
in
something
like
a
you
are
on
a
browser.
So
that's
where
some
of
these
other
other
ideas
come
from
of
the
the
text,
format
and
so
forth.
U
So
yeah
I
understand
it's
debatable
that
whether
or
not
that
should
or
shouldn't
be
part
of
the
specification
but
yeah.
Those
are
that's.
Some
of
this,
a
UID
does
end
up
being
transmitted
to
other
parts
of
the
system
and
I
generally
I
agree
with
the
idea
that
we
don't
want
too
much
detail
in
whatever
specification,
because
it
tends
to
some
of
the
detail.
U
That's
in
the
existing
spec
says
you
need
to
do
all
these
things
to
make
a
valid
UUID
I'm
paraphrasing,
but
that's
kind
of
the
idea
you
get
when
you,
when
you
read
these
things
and
then
some
of
that
detail
is
not
necessary
to
just
communicate
in
a
UID.
That's
been
created
to
other
parts
of
the
system,
but
other
things
are
you
have
to
have
at
a
certain
length
you
have
to
you.
If
you
put
the
version
ID
in
the
wrong
place,
then
you
know
nobody
will
be
able
to
figure
out
which
type
it
is.
G
Eric's
corley
here
I
mean
this
seems
like
a
fine
touchable
design,
but
the
problem
is:
if
I
understand
your
specification,
it
doesn't
actually
guarantee
any
yes,
because
and
as
you
say,
you
see,
justice
locally
and
e-crime
globally,
unique
so
and
I.
Think
we
find
of
a
specification
called
like
non-university
niek
identifiers
would
happen.
We
hunt,
128
bits
and
I
guess
could
have.
U
U
Unquote,
Universal
unique,
you
know
identifier,
so
the
fact
that
making
it
universally
but
in
reality
it
says
unique,
is
your
MAC
addresses
so
I,
just
I
feel
like
it's
an
important
distinction
to
make
and,
however,
it
gets
worked
out
in
this
back
I
think
that
should
just
be
presented
clearly,
as
these
are
the
unique
dis
guarantees
based
on
the
input
but
yeah.
If
that,
if
the
determination
is,
we
should
call
it
something
else,
then
that
I
would
have
no
problem
with
that.
U
K
A
You
for
bringing
that
to
us
it's
very
interesting
discussion
before
I
move
on
to
the
next
draft,
which
is
going
to
be
marks.
Htv
link
that
aircraft
I
plowed
right
through
the
transition
from
The
Dispatch
to
the
art
area,
section
of
our
meeting
you,
if
you
could
see
me
I'm
waving
my
hands
now
I'm
still
a
little
bit
on
accustomed
to
doing
two
meetings
with
respecting
those
boundaries
so
bear
with
me.
One
of
the
things
we
wanted
to
talk
about
in
our
area
are
the
there
we
go
are
some
of
the
buffs
coming
up?
A
A
E
Again
they
do
to
our
format
and
to
get
through
quickly,
I
think.
Maybe
the
chair
should
just
talk
to
these
real
quick
and
then,
if
anyone
wants
to
stand
up
and
say
more,
they
can
sure
why
don't
you
take
the
lead
here?
I
walked
right
into
that.
Didn't
I,
yes,
okay,
so
busy
ready
to
make
that
comment,
not
listening
to
what
you
were
saying
so
I'll
just
jump
in
well.
There
was
th
South
earlier
today.
I
didn't
put
this
on
this
list
because
it's
already.
E
For
it
who
hadn't
already
seen
it,
but
for
some
new
working
groups
coming
up,
we've
got
the
adaptive
DNS
discovery,
that's
kind
of
a
follow-on
to
the
work
from
doe.
That's
like
coming
up
on
Tuesday
Wednesday.
We
have
web
packaging
and
that
is
listed
as
a
boss.
But
it's
a
work
group
information,
so
it's
kind
of
in
between.
E
E
E
I
Only
two
items
on
the
agenda,
but
they
are
both
interesting.
One
is
a
proposal
to
do
something
about
the
updates
tag
at
the
top
of
RFC's
to
make
them
more
useful,
and
the
other
is
a
follow
on
that
has
to
do
with
the
fact
in
part,
the
eligibility
of
folks
to
be
on
nom,
comms
and
other
such
things
if
they
are
remote
participant
which
took
on
new
excitement,
because,
of
course,
everybody
being
remote.
This
time
means
that
you
might
not
meet
the
qualifications
to
be
on
the
NomCom
like
you
would
have
in
the
past.
J
We've
got
four
things
on
the
agenda,
two
of
which
have
HTTP
connections,
one
of
which
is
looking
propagates.
The
client
certs
through
a
clan
cert
information
through
HTTP,
so
from
a
reverse
proxy
or
a
TLS
Terminator,
there's
looking
at
adding
a
sazzle
as
an
authentication
option
HTTP.
So
there's
also
a
couple
other.
You
know
token,
like
things
and
some
discussion
of
attack.
Defense
might
be
interesting
folks
in
the
app
space.
E
A
X
A
Thank
you
for
the
effort
couple
bookkeeping
items
blue
sheets:
if
you're
not
signed
the
blue
sheets,
if
we
have
a
hundred
fifty
people
on
this
conference
call
which
would
be
I,
think
a
great
turnout
for
an
in-person
dispatch
meeting.
So
thank
you,
everyone
for
giving
us
your
time,
no
matter
what
time
it
is
in
your
part
of
the
world,
but
make
sure
you
sign
the
blue
sheet.
It's
on
the
ether
pad
which
you
can
find
linked
off
of
the
agenda
or
at
the
top
the
WebEx
chat.
Okay
mark.
A
S
S
S
S
So
there
are
about
you
know
things
you
could
learn
by
interacting
with
the
resource
using
the
protocol,
but
they're
there
instead
hints
that
you
can
discover
ahead
of
time
and
I
actually
I
think
presented
this
in
the
Arian
meeting,
probably
in
2013,
it's
been
around
for
a
long
time,
and
there
was
light
in
two
respects
then,
and
then
it's
kind
of
set
out
there
I
wasn't
quite
sure
what
to
do
with
it.
I
brought
it
up
again
because
I've
a
fairly
persistent
set
of
folks.
S
S
S
S
Sponsored
I
could
also
see
an
argument
that
maybe
it
would
be
interesting
to
spit
up
a
small
working
group
to
work
on
HTTP
API
related
specifications,
there's
a
bit
of
pent
up
demand
for
that
in
that
community
and-
and
if
that
were
the
case,
I
think
that
there'd
be
a
lot
more
work
than
needed
you
to
heaven.
First,
let's
we're
gonna
get
some
feedback
from
folks
about
where
they
think
they
should
tell.
E
H
Something
like
this
is
actually
a
hot
topic
at
MOG
right
now.
It's
one
of
the
key
things:
I'm,
the
major
mailbox
providers
and
the
major
senders
are
trying
to
do-
is
describe
what's
in
a
URL
payload,
so
that
the
link
doesn't
actually
need
to
be
opened
and
scanned,
and
so
MOG
might
be
a
very
relevant
place
to
have
this
conversation
and
bring
some
of
the
industry
feedback
back
to
a
future
IETF
meeting
or
even
back
to
dispatch.
H
S
That's
really
interesting.
Actually
thank
you.
I
I
will
say
that
I'm
a
little
cautious
here
in
that
this
is
just
a
vocabulary
to
adorn
links
with
without
specifying
how
to
turn
how
to
do
so
and
that's
context
specific.
There
is
a
lot
of
water
under
that
particular
bridge
and
a
fair
amount
of
pain
as
well
in
the
web
services.
Try
to
do
this
in
fluent
references
all
the
different
HTTP
description
languages
of
trying
to
link
description.
It's
it's
a
minefield,
but
yeah.
Oh
really,
so,.
H
Let
me
reframe
it
that,
like
what
we
have
at
MOG
is
a
set
of
very
concrete
use
cases
where
there
is
specific
abuse
that
doing
something
like
this
could
solve,
and
so
it
may
not
be
the
whole
answer,
but
I
think
it
avoids
some
of
those
minefields,
because
it's
very
concrete
the
problems
that
are
being
addressed,
but
but
again
at
MOG.
We
don't
necessarily
know
the
proper
solution
that
actually
gonna
work
at
scale
for
everyone,
so
this
would
be
a
completely
exploratory,
but
we
would
absolutely
welcome
that
conversation.
O
S
K
Thank
you,
I,
just
I
was
just
gonna,
say
I
know,
I
was
doing
a
good
job
of
listing
off
all
the
possible
routes
out
of
dispatch,
and
so
one
of
them
was
hey,
be
sponsored
which
seemed
to
be
like
a
really
bad
fit
for
something
with,
and
he
has
low
energy
for
so
I
was
just
wanted
to
mention
that
my
experience
with
a
the
ad
sponsored
dress
was
not
positive.
I.
J
Mine's,
so
Marga
I'll
expand
a
bit
on
the
link
I
pasted
the
the
idea
I
was
trying
to
convey.
There
is
there's
a
few
of
these
like
specification
languages
out
there
for
saying,
like
here's,
the
rest
API
that
exists
on
this
server,
with
specifying
kind
of
a
bunch
of
similar
details
to
what
what
are
in
this
document.
There's
one.
If
you
had
thoughts
on
like
how
this
doc
would
relate
to
you
know
those
things,
is
it
better
in
some
way
worth
doing,
you're
more
worth
doing
here
for
some
reason,
so.
S
This
is
actually
not
competing
with
those
languages.
I
have
another
document
that
some
would
think
it
does,
but
others
mincemeat
doesn't
that's
a
different
discussion.
This
is
more
like
a
vocabulary
that
they
can
use
and
I
think
some
of
the
folks
who
are
interested
actually
intend
to
used
in
that
fashion.
So
it's
a
way
you
can
decorate
your
Langston.
Y
S
Yeah,
so
the
this,
the
discussion,
unfortunately,
is
shotgun
across
probably
a
decade
and
a
half
of
work
in
both
web
services
and
HTTP.
Api
I
can't
point
to
any
one
resource
but
I'm
happy
to
discuss
stuff
offline.
If
you
want
in
regarding
what
you
just
said.
Yes,
absolutely.
That
is
a
risk.
It's
not
the
people
who
want
to
use
these
aren't
really
looking
at
doing
things
where
I'm
talking
about
your
resources.
For
example,
it's
more
about
what
I'm
talk
about
my
resources.
A
E
A
S
Welcome
yes,
III
I
have
to
say:
I
was
I
was
thinking
the
charities
work.
It
would
be
interesting
to
discuss
the
possibility
of
a
working
group
to
work
on
h-tpa
PR,
related
specifications.
I
think
it
could
go
horribly
wrong,
but
it
also
might
improve
the
world,
but
I
think
that's
a
much
longer
term
of
discussion.
In
the
meantime,
this
is
a
fairly
compact,
relatively
straightforward
thing:
I'm,
not
sure
if
it
needs
a
working
group
or
not.
P
A
Maybe
we
should
expand
on
that
idea
right
and
and
discuss
what
a
charter
for
that
might
look
like
and
put
that
forward,
see
if
that
is
a
dispatch,
II
item
or
not,
okay,
I
think
I.
Think
this
link
decoration,
you
know
they
should
be.
This,
could
processes
if
they
wanted
to
and
I
don't
think
I'd
want.
You
know
really
any
other
machinery
around
it
just
due
to
weight
if
it
we're
gonna,
be
the
only
thing
but
I
think
you've
got
a
point
that
it
won't
be
the
only
thing
and.
E
I'm
in
queue
next
and
and
I
will
comment
that
when
you
sent
this
originally,
you
were
hoping
we
could
get
this
done
on
the
mailing
list
and
obviously
that
didn't
happen.
I
wondered
now
that
you've
had
a
chance
to
talk
about
it.
If
people
have
a
chance
to
think
about
it
in
our
next
step
is
not
to
turn
around
and
re.
Ask
some
of
the
dispatch
questions
on
mailing
lists
from
the
chairs
and
and
sometimes
like
really
shortly
after
this
meeting
and
see
what
conversation
goes
there
or
or
do
Patrick
or
ATS?
A
S
So
can
I
suggest
why
don't
I
go
off
and
explore
the
idea
of
what
a
charter
for
that
other
working
group
might
look
like
and
try
and
engage
with
the
folks.
I
know
who
work
on
HTTP
API
is
a
lot
to
see.
If
we
can
get
some
amount
of
motion
behind
that,
and
if
we
can,
then
we
can
bring
that
back
and
discuss
it
in
what
might
be
migrated
exactly.
S
A
A
E
A
AA
Thanks
so
hi
everyone,
my
name
is
Maxime
Chewbacca
I
present
a
certain
research
and
development
team
at
high
vision,
on
behalf
of
a
vision
and
SK
Telecom
I'm
producing
the
secure,
reliable
transferred
protocol.
So,
due
to
time
limitations,
I
was
asked
to
only
share
the
motivation
key
features
of
the
protocol
so
that
we
can
discuss
which
track
to
go
and
continue
more
technical
discussions
on
the
dedicated
working
group.
So
next
slide.
Please
briefly:
SRT
is
the
protocol
built
on
top
of
UDP
this
content
agnostic.
AA
It
provides
bi-directional
data
transmission
with
automatic,
repeat,
request,
forward,
error,
correction
and
bonded
connections.
It
also
supports
three
multiplexing
so
that
several
connections
can
be
established
over
a
single
UDP,
sockets
and,
of
course,
encryption.
The
major
purpose
and
use
case
of
a
30
is
low.
Latency
live
video
contribution
and
distribution
over
unreliable
networks.
Next
slide,
please,
sir
T
was
created
and
first
used
in
2013
in
2017.
30
was
made
open
source
and
free
for
public
usage.
AA
At
the
moment,
a
cert
is
an
open
source
library
based
protocol
that
has
been
widely
adopted
and
has
become
a
de
facto
industry
standard
for
live
contribution
and
distribution
companies
using
a
30
adjoining
the
30
Alliance
that
currently
counts
more
than
350
members.
Only
last
year,
more
than
100
new
companies
had
joined
the
search
Alliance.
Also
last
year,
30
received
the
technical
Emmy
Award.
All
these
are
good
indicators,
that
is
a
is
a
highly
demanded
solution
of
a
still
topical
problem
of
life,
contribution
and
distribution.
AA
So
it
is
very
flexible
multi-purpose,
content,
agnostic,
it's
open
source
of
limitations
were
easy
to
use
because
it
provides
a
PLC
module,
UDP
and
TCP
and
circuit
api's,
and
so
the
lever
is
backward
compatible
so
that
the
latest
version
still
supports
previous
versions
of
the
library.
Next
slide.
Please
up
until
today.
30
is
an
implementation
driven
protocol,
but
it
is
about
time
to
provide
an
official
specification
of
the
protocol
so
that
everyone
can
use
it
to
write
an
independent
implementation
and
be
sure
to
be
compliant
with
others.
AA
That
is
one
of
the
requests
we
get
from
our
community
and
one
of
the
reasons
for
certainty
to
be
presented
to
IETF
in
other
motivation
is
to
become
a
part
of
great
idea
of
community
to
get
available,
feedback
and
experience
and
continue
improving
at
the
protocol.
Next
slide,
please.
So
to
give
you
a
quick
idea
about
the
protocol
secure
for
several
operations,
mods
message,
mod
live
mod
and
buffer
mod
message.
Mod
can
be
used
to
reliably
transmit
messages.
That's
been
over
several
packets
life.
AA
Mods
is
a
subset
of
message,
mod
with
additional
features
to
enable
a
real-time
live
stream
transmission
with
the
constants
end
to
end
latency
and
possibility
to
drop
packets.
So
that's
a
reliable
delivery
within
a
certain
latency
window
and,
finally,
buffer
mod
is
used
to
open
a
connection
transmit
a
single
and
large
piece
of
data
and
close
the
connection
next
slide.
AA
The
major
purpose
and
use
case
of
a
30
is
low.
Latency
live
video
contribution
and
distribution,
the
corresponding
abridged
model,
sir.
He
is
called
live
mode.
The
live
mode
provides
a
fixed
end-to-end
latency
that
includes
network
transmission,
latency
and
a
configurable
buffering
delay
of
the
receiver
to
recover
packet
losses
on
the
receiver
delivers
the
packets
to
an
upstream
plication
not
earlier
than
after.
The
specified
latency
has
expired
next
slide.
AA
Life
mode
provides
an
additional
benefit
of
recovering
the
timing
of
the
source,
VBR
streaming
that
can
be
distorted
by
network
transmission.
This
recovery
of
timing
helps
decoders
in
playback
devices
to
add
only
minimal
additional
latency
for
decoding,
while
the
whole
management
of
them
to
end
latencies
before
by
assert,
so
that
application
doesn't
need
to
implement
and
handle
it
itself.
AA
K
I
keep
pushing
my
mute
button
and
it
keeps
wiggling
around
sorry.
Thank
you
for
bringing
this.
The
questions
that
I
would
be
curious
about
would
be
whether
you
intend
to
work
on
this
protocol
further
or
whether
you
need
to
whether
what
you
need
to
do
is
publish
what
you've
got
and
if
you
need
to
publish
it
as
an
RFC
as
a
stable
reference
doesn't
need
to
be
an
IETF
standards
track
protocol,
but
Helen
Perkins
said
it
had
a
third
question
that
I
lost
one
dawn.
K
So
the
third
question
was:
how
does
this
just
differ
from
other
ITF
work
and
I?
Think
that
my
first
two
questions
would
tell
you
how
many
quite
more
questions
you
need
to
answer
about
this.
If
it
needs
you
know,
if
it
just
needs
to
be
we'll
see
what
you've
got.
That
means
something
it
needs
to
be
if
it
just
needs
to
be
publishing
what
you've
got
as
a
standard
track
document.
That
means
something
else.
So
I
would
ask
you
to
think
about
those
two
questions.
First,.
AA
Thanks
very
much
questions
really
one
of
the
questions
we
consider
to
discuss
with
ITF,
so
the
30.
We
want,
first
of
all,
to
specify
what
we
already
have,
so
that
our
community
doesn't
lose
the
compliance
and
within
this
domain
of
what
we
have,
we
can
potentially
increase
and
add
some
features,
but
still
remain
in
the
compliance.
So,
for
example,
we
can
add
some
more
encryption
techniques,
so
we
can
add
some
other
mechanism
and
so
on.
So
that's
one
one
purpose
of
our
our
work
and
maybe
for
this
bin.
AA
K
So
the
two
things
I
would
say
there
is
we
have
in
the
past
I'm
even
chairing
a
working
group.
Now,
that's
you
know.
Here's
we're
publishing
here
are
versions
of
something
that
we've
already
done,
but
we
didn't
do
them
at
the
IETF
and
those
will
be
informational
and
then
we'll
publish
what
we're
working,
what
we're
working
on
now
that
they
want
that
the
people
wanted
help
with
and
that
was
going
to
be
published
in
our
case
as
a
standards
track
document.
Maybe
you
know,
maybe
maybe
even
informational
would
be
okay
for
you
for
that
too.
K
But
you
know
some
people
bring
us
things
where
what
they
really
want
is
X,
you
know,
is
a
lot
of
eyes
on
something
and
bring
it
to
the
ITF
for
review
and
then
publication
after
the
review.
Is
you
know
it's
what
they
want?
So
just
asking
you
to
be
kind
of
clear
in
your
mind
about
what
you're
hoping
happens.
AA
J
Hey
I
was
just
wondering
yeah,
since
security
wasn't
the
name,
and
it
got
my
attention
on
it,
so
wondering
if
you
could
kind
of
confirm
kind
of
what
the
security
assumptions
are
around
this.
Normally
with
things
like
TLS
or
quick,
we
assume
that
the
two
parties
don't
have
anything
in
common
besides
some
public
data,
whereas
this
it
looks
like
on
a
haven't
dive
deeply
into
the
specification,
but
it
looks
like
there
is
an
assumption
here,
there's
some
pretty
key
material
pre-configured
between
the
endpoints.
So
that's
kind
of
one
question
there.
J
The
question
I
had
is.
It
looks
again
from
a
very
brief
review
of
the
crypto
here,
like
some
of
the
standard
things
we
do
in
the
ITF
these
days
and
doing
modern
protocols
like
using
a
EAD
algorithms
pretty
much
everywhere
in
forward
secrecy
might
not
be
here
so
I'm
wondering
like
if
we
were
going
to
do
some
work
here.
How
much
flexibility
would
there
be
to
kind
of
update
those
security
myths
to
a
more
modern
foundation?
Thanks.
AA
AA
So
it's
actually
a
standard
approach
to
do
it,
but
still
both
parties
should
have
a
common
ppreciate
passwords
to
establish
the
reliable
connection,
but
still
a
30
provides
mechanisms
and
provides
additional
field.
Extensions
of
the
handshake
to
improve
this,
and
if,
for
some
use
cases
you
need,
for
example,
TLS
handshake.
We
are
also
free
to
consider
how
it
will
how
it
will
connect
with
a
30
I
think
it
should
should
work
as
well.
D
J
AA
Well,
as
I
can
tell
right
now,
I
think
it's
so
a
cert
is
very
open
to
this,
because
so
you
have
two
phases
or
when
its
encryption
first
is
how
you
negotiate
the
certain
encryption
mechanism
and
algorithm
that
can
be
extended
for
sure,
with
with
means
of
handshakes
and
second
parts.
Github
is
how
you
encrypt
the
payload
so
SRT,
it's
only
the
payloads
of
data
packets,
it
doesn't
can
encrypt
heaters
and
how
you
encrypt
the
payload
is
again
up
to
so
it
can
be
extended
to
adventure.
G
Hi
thanks
for
the
presentation,
I
guess
one
thing:
I
didn't
quite
get
from
your
presentation
or
the
discussion.
The
mailing
list
is
like
what
functionality
this
have
that
quick
does
not
so
I
mean.
Is
this
just
a
matter
if
you
have
a
technology-
and
you
don't
want
to
like
change
everything
or
is
there
some
sort
of
functionality
that
this
has?
That
like
makes
it
substantially
better
than
quick
and
it
could
be
easily
adapted
to
quick.
AA
Things
for
another
good
question,
so
as
far
as
I
understand
tweak,
it
proposes
the
Datagram
extension
that
is
being
under
development
right
now
and
if
I
understood
it
correctly,
it's
more
like,
let's
say
yes,
EGP
extension,
its
UDP
with
encryption
and
with
kind
of
feedback.
If
I
understood
it
correctly,
what
asserted
us
it's?
It's
not
something
you
and
unique,
so
you
can
combine
several
other
protocols
and
build
single
pipelines,
similar
workflow
but
assert.
It
provides
everything
out
of
the
box.
AA
The
main
purpose,
if
is
life,
streaming
contribution
and
distribution,
and
you
have
one
bi-directional
channel
that
is
encrypted,
that
provides
jitter
management,
latency
management
package,
origin
management
and
so
on,
and
so
that,
if
you
have
an
application
that
needs
to
work
with
live
streaming,
you
don't
need
to
bother
and
to
implement
it
yourself
or
to
collect
several
protocols
and
organize
an
infrastructure
for
them
like
several.
There
are
connections
and
so
on
all
is
available
out
of
the
box
and
that's
the
major
purpose
of
a
certain
one
of
the
use
cases.
R
K
AA
K
I'm
sorry
I
was
not
have
been
clear,
so
we've
had
so
you
know
the
first
thing
you
know:
you've
got
a
you've
got
a
UDP
base
protocol,
and
so
we
would
ask
questions
about
how
safe
that
is
for
use
over
the
open
Internet,
especially
if
you're
talking
about
file
transfers
where
you're,
not
sender,
limited.
You
may
not
be
sender
limited
on
how
fast
you
can
transmit.
K
So
you
know
number
one
is:
is
this
safe
for
operation
over
the
open,
Internet
and
number?
Two
is,
if
you
you
know,
if
it
has
enough
congestion
management
capability
to
be
safe
on
the
open
Internet,
are
you
going
to
need
to
evolve
that,
as
we
come
up
with
new
congestion
control
mechanisms
that
would
have
better
performance
characteristics
that
you
would
just
want
to?
K
AA
Okay
and
thank
you
for
clarification-
yes,
that's
something
that
was
on
my
presentation.
If,
if
slide
16
can
be
open,
so
I
would
appreciate
that
so
just
to
give
the
idea
I
search,
it
provides
certain
mechanisms
that
are
very
similar
to
quick
mechanisms.
A
sortie
sends
acknowledgement
packets
and
these
acknowledgment
packets
have
additional
fields
from
the
receiver
that
estimates,
for
example,
RTT
estimates,
link
capacity
and
other
measurements
receiving
speed
and
so
on.
So
center
gets
certain
feedback
from
the
receive
on
that
and
another
mechanism
and
another
feedback
is
negative
acknowledgement
packets.
AA
So
when
there
is
a
gets,
a
lost
receiver
also
sends
negative
acknowledgement,
packets
and
sentinels
the
amount
of
losses
in
this
transmission.
So
that's
any
congestion
control
can
utilize
this
data
to
implement
certain
algorithms.
On
top
of
it
and
SRT,
we
have
two
types
of
congestion
control:
one
is
for
live
mode.
You
know,
that's
the
slide,
so
one
is
for
life
modes
and
the
unique
unique
feature
of
life
mode
is
that
you
have
limited
source
bitrate.
So,
for
example,
you
have
live
stream
of
10
megabits
per
second,
and
you
can't
go
above
that
right.
AA
So
here
you
have
certain
possibilities
to
control
how
you
do
your
pacing,
how
you
do
retransmissions
and
so
on.
So
that's
one
part
of
a
circuit
that
is
already
used
and
also
based
on
this
acknowledgment
feedback
and
negative
acknowledgment.
It
work.
Another
part
is
file
transmission
and
that's
again
so
bbr
cubic
all
this
can
be
used
on
top
of
I,
can't
not
make
it.
So
that's
completely
extensible
and
very,
very
flexible.
AA
K
K
G
AA
D
N
AA
E
AA
Z
AA
That's
a
good
topic
for
discussion
to
me.
Why
quick,
his
being
good
for
this
purpose
is
because
a
lot
of
browsers
and
chrome
engine
already
supports
this
protocol.
So
here
we
have,
let's
say
more,
a
topic
of
discussion:
how
to
to
be
included
in
this
engine.
If
we
require
it
or
in
other
potential
route,
is
to
go
on
top
of
some
kind
of
WebSockets
and
try
to
do
but
I
think
that
would
be
a
bit
tougher.
V
Hi,
a
number
of
people
have
asked
about
how
this
relates
to
quick,
I'm,
going
to
ask
the
the
other
question,
which
is:
how
does
this
relate
to
RTP
the
real-time
transport
protocol?
We've
had
a
lot
of
work
in
that
space
over
many
many
years
in
the
IETF,
and
it
sounds
like
there's
a
lot
of
similarities
what's
different
here.
AA
Thanks
for
question
again,
sorry
is
not
something
that
can
cannot
be
found
in
other
protocols,
but
it's
it's
a
mix
of
all.
You
need
for
livestream
in
hand
with
our
RTP.
You
have
unreliable
delivery
over
UDP,
so
you
have
time
stamps
on
the
packets.
That's
okay,
but
still
you
don't
have
the
backwards
track
so
for
backward
track,
use
additional
link,
additional
connection
like
a
TCP
or
RTSP
to
control
this
flow
and
again
it
doesn't
provide
you
all
you
needs
with
Sarty.
You
get
all
deaths
in
one
bi-directional
connection,
so
you
get
live
stream.
AA
Possibilities
ends
with
four
examples:
three
multiplexing!
You
can
also
get
additional
features.
For
example,
one
of
the
use
cases
surgery
is
used
is
is
when
a
video
operator
on
fields
record
the
video
and
live
streams
its
to
the
the
production
sensor
and
in
the
production
center
producer
might
send
feedback
to
this
video
reporter.
Also
on
this
very
circuit
connection,
so
you
can
establish
on
the
same
VDP,
sockets,
live
stream
and
connection.
You
can
establish
on
the
same
DP
circuit
as
a
multiplexed
stream
message,
interchange
and
so
on.
So
that's
the
convenience
of
srt.
AA
Of
course,
but
again
the
main
purpose
is
that
you
get
everything
out
of
the
box.
So,
for
example,
you
get
you
can
get
live
streaming,
you
can
get
message,
interchange
and
so
on
and
that's
all
like
the
latency
management
is
managed
by
a
30.
So
when
you
implement
an
application,
you
don't
you
don't
do
this
logic
on
your
own
again,
as
I
said
you
can,
you
can
use
RTP,
you
can
use
additional
protocols
to
provide
this
stuff
and
it's
it's
completely.
Ok,
it
depends
on
the
use
case.
You
have,
but
again
what?
AA
If
you
don't
want
to
TB
what,
if
you
want
and
bacterias
right
away
with
SOT,
you
can
do
it
with
a
30.
You
can
also
put
our
TB
inside
of
a
certainty
bill.
It's
completely!
Ok
as
well,
so
it's
just
I
think
another
way
to
check
the
rate
with
this,
and
we
appreciate
the
work
with
RTP,
and
so,
if
we
can
discuss
how
we
can,
for
example,
improve
and
cooperates
and
mix
all
together,
but
also
good
for.
A
This
is
thank
you
so
much
for
the
presentation
and
the
questions
are
generated
as
we
consider
from
a
dispatch
point
of
view.
You
know
where
this
might
fit
into
the
IETF
universe.
I
I
think
I
want
to
clarify
something
that
came
up
on
the
list,
and
that
was
the
question
of
whether
this
is
intended.
As
a
you
know,
a
specification
that
cannot
change
because
it's
deployed
in
multiple
products
or
if
this
is
an
area
that
we
want
protocol
standardization
on
and
intellectual
contributions
from
working,
because
those
would
proceed
into
very
different
paths.
A
AA
Will
say
would
be
good
to
have
this
specified
as
it
is
right
now
and
have
potential
to
extend
within
this
specification.
So
if
we
don't
change
the
existing
handshakes
much
and
we
don't
change
the
30
heaters
that
are
kind
of
fixes,
that
would
be
great
because
this
protocol
is
already
being
used
and
the
part
of
that,
if
some
additional
improvements
arise
and
I
think
there
are
some
parts
that
can
be
proved.
We
can
can
start
some
efforts
to
have
a
separate
version,
additional
version
of
sure.
So.
A
The
usual
advice
in
a
situation
like
that
would
be
that
you
work
with
the
individual
submissions
editor
to
try
and
get
a
specification
published
in
a
Nam
protocol
stream
or
non-standard
stream.
For
that,
and
then,
once
that's
established,
we
can
talk
about
where
the
IETF
might
be
able
to
do
work
for
your
extensions
of
that
kind
of
thing.
I
mean
there
I
want
to
speak
for
the
group,
but
that
would
be
I
think
the
fairly
typical
advice.