►
From YouTube: IETF102-DISPATCH-20180716-0930
Description
DISPATCH meeting session at IETF102
2018/07/16 0930
https://datatracker.ietf.org/meeting/102/proceedings/
B
A
A
C
All
right,
okay,
so
the
official
mouth
submission
is
earlier
than
any
of
our
guidelines.
So
people,
if
you
think
you
have
something
that's
going
to
be
fairly
large,
then
you
really
need
to
start
talking
about
it
earlier.
So
second,
the
28th.
That's
the
deadline
just
to
let
us
know
that
you
have
a
topic
and
then
ideally
October
5th.
We
want
cutoff
return
of
proposals
and
my
tarter
we
mean
we
want
a
clear
problem
statement.
C
A
And
I
will
highlight
on
this
to
of
just
the
barge,
and
you
know
it
could
get
this
out
to
us
early
first,
we
can
help
give
advice
about
whether
you
might
want
to
do
it
in
dispatch
or
as
a
major
office
on
our
mailing
lists.
Where
we're
doing
our
discussion
will
remind
everyone
of
that
and
I
think
that
we
will
now
move
on
to
the
reason.
I
am
sure
everyone
came,
which
one
of
the
best
turnouts
I've
seen
in
dispatch
a
long
time.
Thank
you
for
all
coming
the
helium
Drive.
So.
E
Okay,
thanks
everybody
for
coming
I'm
here
to
talk
about
a
new
working,
okay,
I,
don't
have
to
figure
out
how
to
use
it.
The
expert
everybody
for
coming
this
is
a
very
early
stage
proposal.
Unfortunately,
due
to
the
ordering
of
HTTP
bifs
and
dispatch,
this
meeting
things
are
in
a
little
bit
of
a
confusing
order.
E
So
I'll
be
talking
about
this
part
of
of
a
larger
idea
here
in
dispatch
and
then
Lukas
pardhu
will
be
leading
a
presentation
for
a
few
minutes
in
HDTV
this
on
a
little
bit
of
a
broader
perspective,
on
what
we're
talking
about.
Why
we're
talking
about
it?
So
I'll
try
to
make
this
intelligible,
even
though
we're
a
little
bit
out
of
order.
E
So
the
the
goal
here
is
is
UDP
proxying
and
the
inspiration
is
the
impending
arrival
of
quick.
So
HTTP
has
been
self
proxying
since
HTTP
1.1.
So
that's
the
idea
that
you
can,
within
the
HTTP
protocol,
ask
an
HTTP
server
to
forward
a
request
for
you
to
some
destination.
Now
that
doesn't
mean
that
the
server
has
to
actually
do
this,
but
at
least
it
gives
you
a
way
to
make
the
request
participating
servers
can
offer
this
functionality.
E
E
Currently,
if
you
set
up
a
proxy
browsers,
have
to
actually
disable
all
of
their
quick
functionality,
because
there's
no
way
to
ask
the
proxy
to
forward
a
quick
stream
to
a
destination
because
quick
runs
over
UDP
and
there's
no
HTTP
mechanism
for
forwarding
UDP
packets.
So
that
is
the
inspiration
here.
Could
we
have
UDP
proxying
in
an
HTTP
system
so
that
we
maintain
this
self
proxying
feature
for
quick
and
we're
going
to
be
doing
you?
You
proxying,
then
well,
it's
useful
for
a
bunch
of
other
stuff,
too.
E
It's
useful
for
WebRTC,
which
currently
uses
turn
as
a
UDP
forwarder,
and
also
you
know
it's
a
UDP
forwarding
is
a
lot
like
VPNs
I'll
get
back
to
that
in
a
second
you
know.
Could
we
somehow
cover
some
of
those
use
cases
too?
Maybe
we
could
even
do
something.
That's
sort
of
halfway
between
a
UDP
proxy
and
a
VPN
I'll
talk
about
that
in
a
bit.
So
the
goal
is
to
see
if
we
could
find
a
protocol
that
could
cover
all
these
different
use.
E
Cases
is
pretty
simple
and
really
works
nicely
in
an
HTTP
oriented
system.
So
my
claim
to
you
is
that
a
UDP
proxy,
so
here's
the
on
the
left
here.
This
is
basically
my
my
summary
of
the
features
offered
to
you
by
turn.
It
gives
you
I
P
addresses
it
gives
you
the
contents
of
UDP.
Udp
header
gives
you
the
contents
of
the
UDP
payload.
It
gives
you
a
stable
port
mapping.
E
This
is
just
IP
and
net
in
a
sort
of
in
a
different
formulation,
but
fundamentally
the
the
information
that
we're
talking
about
here
is
the
information
that's
in
an
IP
packet
and
the
function
that
the
proxy
is
serving
is
very
similar
to
the
function
that
a
NAT
is
serving
in
a
network.
Of
course,
the
the
pieces
have
been
taken
apart
and
put
together
in
a
different
order,
but
but
that's
the
data
that
we're
really
moving.
E
So
this
is
the
helium
idea.
The
idea
is
maybe,
instead
of
building
a
UDP
proxy
in
an
explicit
way,
like
turn
does
or
like
socks5
UDP
does.
Maybe
we
could
just
take
UDP
and
put
it
on
top
of
IP
and
just
use
the
IP
header
to
move
that
information
and
then
maybe
there's
some
kind
of
tiny
wrapper
that
we
need
around
IP.
If
there's
a
little
bit
of
information
that
doesn't
quite
fit
into
the
IP
header
and
then
all
that
can
run
over
some
sort
of
really
good
transport.
E
That
gives
us
message:
oriented
semantic
security,
congestion
control
flow
control,
all
that
kind
of
good
stuff.
So
we
don't
have
to
reinvent
all
of
that.
So
the
helium
describes
two
things:
it
describes
in
first
an
abstract
protocol
and
then
one
sort
of
concrete
possible
instantiation
of
that
protocol.
So
the
the
abstract
protocol
actually
barely
even
mentioned
UDP.
It
just
describes
something
based
on
IP
was
designed
to
be
usable
in
UDP.
Only
systems
there's
this
thing,
which
is
probably
going
to
get
renamed
currently
called
helium
inter
protocol.
E
It's
just
a
very
thin
header,
I'll
show
it
on
the
next
slide.
It
just
does
a
tiny
bit
of
information
that
you
might
want
to
add
in
addition
to
what's
in
an
IP
packet,
and
then
it
transport
is
sort
of
not
specified
at
that
layer
and
then
there's
a
concrete
instantiation.
So
in
a
concrete
instantiation
you,
you
would
take
that
header
and
encode
it
in
some
way.
E
So
here's
the
the
entire
actually,
basically
the
entire
helium
protocol-
in
a
nutshell,
you
can
send
a
packet,
you
can
receive
a
packet
and
the
one
sort
of
interesting
new
thing
really
well
I'll
cover
a
few
more
of
these
details
on
the
next
slide
is
that
you
can
find
out
what
happened
to
your
packet,
so
that
I
think
is
my
view
here.
Is
that
basically,
this
is
what
distinguishes
a
proxy
from
a
VPN,
essentially
VPNs
forward
your
packets
and
in
the
process.
E
They
have
to
transform
them
in
a
certain
way
and
generally
there's
no
way
to
for
you
to
find
out
exactly
how
that
transformation
occurred.
If
you
can
send
a
packet
and
also
understand
on
the
client
what
transformations
the
remote
endpoint
applied
to
your
packet,
then
I
claim
that
that
essentially
is
a
proxy
server
in
the
sense
that
we're
talking.
So
the
goal
here
is
to
sort
of
split
the
difference
to
cover
both
cases.
E
So
the
the
most
interesting
thing
here,
there's
a
I'll
talk
in
a
little
more
detail
about
some
of
the
fields
here
and
why
they're
here,
as
I
said,
this
is
all
very
early
stage
work.
So
I
don't
expect
that
this
is
going
to
just
you
know,
stay
this
way,
but
the
most
interesting
mechanism
here
is
the
thing
at
the
bottom.
The
last
line
that
the
way
you
find
out
what
happened
to
your
packet
is
that
the
server
echoes
to
you.
E
If
you
request
this
information,
the
server
will
echo
to
you
a
packet
prefix
containing
any
modified
portions
of
the
outbound
packet.
Did
you
send
a
packet?
The
server
had
to
modify
it
in
certain
ways
and
you
get
you
get
if
you
want
an
echo
back
of
any
aspects
of
the
packet
that
we're
altered.
So
this
is
basically
an
ICMP
style
mechanism
for
building
a
proxy.
So
this
is
inspired
by
ICMP
error
responses.
E
Where,
if
something
strange
happens
in
the
network,
you
can
try
to
find
out
what
happened
because
ICMP
will
will
show
you
the
beginning
of
your
packet.
So
this
allows
us
to
avoid
inventing
a
new
protocol
for
ultimately
transmitting
a
bunch
of
IP
related
information
and
also
potentially
headers
beyond
the
IP
header.
So
if
your
proxy
server
needs
to
do
things
like
rewrite
UDP
source
ports,
that's
fine!
E
E
The
goal
here
is
that
there's
no
artificial
limitations
within
the
protocol,
so,
for
example,
turn
explicitly
is
unable
to
to
represent
a
bunch
of
of
different
things
that
you
might
want
most,
notably
it's
unable
to
represent
ICMP,
for
example.
So
you
can't
do
things
like
Pat
them
to
you.
Discover
your
traceroute
using
the
standard
ICMP
mechanisms
through
a
turn
circle,
but
also
this
allows
us
to
proxy
any
kind
of
potentially
crazy,
IP
packet
that
you
might
want
to
for
me
now.
E
I'm,
there's
no
guarantee
here
that
it's
going
to
work
in
a
sense,
everything
about
this
design
is
best
effort,
and
but
crucially,
if
anything
doesn't
work,
you
can
always
find
out,
because
you
can
get
a
reply
from
the
proxy
that
says
no
actually
I'm
not
capable
of
doing
whatever
weird
ie
extension.
You
asked
for
a
weird
idea:
option
you
you
propose
doing
so.
Here's
here's
some
fun
stuff
that
you
can
do
in
this.
In
this
very
simple
design.
E
You
can
build
a
UDP
and
ICMP
proxy
that
doesn't
require
socket
raw
chakra
style
access
right.
You
don't
actually
need
to
be
able
to
form
IP
others.
This
is
inspired
by
the
stun
traceroute
draft
from
well
from
the
the
stun
proposal,
so
that
you
can,
you
can
actually
just
use
the
error
codes
in
the
POSIX
socket
API
to
basically
totally
build
a
thing
of
all
proxy,
both
UDP
and
ICMP,
which
could
be
useful
for
more
advanced
clients.
E
There's
a
one
of
the
reasons
so
that
there's
a
lot
of
people
who
contributed
ideas
here,
I'm,
not
sure
they
all
actually
want
to
be
credited.
But
one
of
the
goals
here
is
to
build
something
that
can
help
bridge
networks,
especially
cell
networks
that
have
two
parts
to
the
path
with
very
different
path:
characteristics,
Wireless,
leg
and
then
a
you
know
a
leg
through
the
through
the
core
of
the
Internet.
E
So
the
the
proxy
adds
timestamps.
Actually
it
can
timestamp
both
incoming
and
outgoing
packets
and
timing.
Aware,
client-side
congestion
controller
could
use
that
to
separately,
observe
latency
past
the
proxy
between
the
proxy
and
the
destination,
so
poor
congestion
and
latency
on
the
client
of
proxy
link
through
whatever
transport
is
being
used,
so
that
could
allow
more
advanced
congestion
control
systems
that
that
adapt,
and
the
goal
here
is
to
be
able
to
avoid
some
of
the
tcp
over
tcp
serious
misbehaviors
that
that
can
usually
occur
when
you
have
multiple
layers
of
congestion,
control
and
packet
loss.
E
Recovery
domain
override
is
is
in
here
so
that
in
a
quick
context,
for
example,
you
might
want
to
contact
a
server
by
name.
It
would
be
nice
to
avoid
having
to
do
a
DNS
lookup
through
the
proxy
and
get
an
IP
address
and
then
try
again
so
domain
override,
says
I'm.
Just
gonna
ask
the
proxy
to
send
this
packet
to
a
particular
domain
and
there's
a
little
bit
of
language
about
how
that
has
to
work
in
order
to
make
that
actually
function
correctly
and
then
DNS
server
indexes.
What
if
I
want
to
do?
E
Dns
queries
to
to
the
proxies
preferred
DNS
resolver,
so
I
want
to
use
a
local
nearby
resolver
for
that
networks,
but
I
don't
just
want
to
send
address
queries.
I,
don't
just
want
to
connect
to
some
IP
address,
I
actually
want
to
do
TLS,
a
lookups
or
yes
and
I
look
up
or
whatever
the
this
would
allow
that
so
there's
a
bunch
of
other
weird
stuff.
The
last
thing
here
is
kind
of
funny.
G
E
You
can
use
the
meta
reply
to
find
out
what
address
it
was
because
you're,
your
source
port
is
rewritten.
So
that's
a
that's
about
it.
For
for
the
helium
itself
and
and
the
other
concept
here
is
how
would
you
use
over
a
website?
So
the
idea
here
is
that
if
a
client
is
aware
of
a
protocol
like
this
and
the
server
wants
to
implement
it,
then
first
the
server
that's
on
the
left.
E
This
is
an
standard
proxy
connection
to
a
server
so
on
the
left,
the
server
can
say
by
the
way:
here's
a
here's,
a
helium
proxy
that
I'm
operating
that
you
also
welcome
to
use
and
on
the
right.
This
is
the
client
actually
connecting
to
that
proxy,
so
reassuring
their
proxy
authorization.
Header
show
that
they're
still
authorized
to
use
it
and
indicating
the
protocol,
and
also
just
for
fun,
indicating
compression
because
WebSockets
support
compression.
E
A
Have
to
sort
a
clarifying
question
about
the
sort
of
the
Nats
I
got
it
to
a
certain
degree,
which
is
in
some
of
the
other
stuff
we've
discussed
sort
of
filtering
this.
Is
this
binding
address
idea
right?
What
what
do
you
envision?
It
will
do
I
mean,
would
different
clients
on
the
inside
be
able
to
use
the
same
port
number
on
the
outbound
side
with
traffic
coming?
E
My
expectation,
the
the
current
you
know
this
is
a
zero
zero,
but
the
the
current
language
in
the
draft
says
I
believe
that
the
that
the
proxy
must
it
so
so
if
the
proxy
is
UDP
aware
that
we
should
say,
because
it's
actually
possible
to
build
a
helium
proxy
that
doesn't
even
know
what
UDP
is
that
operates
strictly
at
the
IP
layer.
But
if
you,
if
you
build
a
helium
proxy,
that
is
UDP
aware
the
draft
says
that
it
should
that
it
should
have
address
dependent
filtering
semantics.
So
so
it
should
essentially
be.
E
H
H
E
H
E
H
E
E
I
think
is
to
to
decouple
these
things
so
to
run
at
a
high
enough
semantic
layer
that
you
know
that
we
run
essentially
over
HTTP
or
over
some
HTTP
related
protocol,
and
then
HTTP
itself,
hopefully
will
run
over
quick
and-
and
so
we
will
at
least
have
have
an
option
that
has
the
right
performance
characteristics.
Okay,.
H
E
H
I
How
does
all
this
John?
Can
you
go
back
to
your
first
read
that
one
I
believe
that
the
first
bullet
is
the
way
I
understand
the
words
proxy
and
HTTP
is
false,
as
in
the
the
inclusion
of
the
domain
of
the
address
of
the
server
in
the
identity
of
the
of
the
overlay
source
was
a
stupid
design
mistake
of
HTTP
0.9
and
the
host
header
was
an
attempt
to
get
us
out
of
that
rat
hole.
We
haven't
gotten
out
of
it,
but
I
believe
that
substantially.
I
Second,
I'm
worried
about
running
to
congestion
control
mechanisms
on
top
of
each
other.
It's
a
stupid
idea.
It
was
a
stupid
idea,
an
ATM.
It
was
a
stupid
at
the
end
in
in
this
radio
length
protocol
that
we
keep
on
using.
It
was
a
stupid
idea
in
many
different
contexts,
and
it
will
I
think
it
will
remain
a
stupid
idea
in
the
future,
so
either
this
works.
I
Third
problem
I
have
here
is
that
this
concept
of
UDP
you're
defining
a
service
for
putting
packets
on
the
internet
and
surrounding
it
with
a
lot
of
pointers
towards
things
like
DNS
and
address
allocation
and
ICMP
and
so
on.
But
you
talk
as
if
you
provide
you
the
fee
to
the
clients
now
about
10
years
ago,
we
have
the
15
years
ago.
We
have
a
protocol
for
for
telling
your
networks
to
send
packets
on
your
behalf
are
safe
and
it
never
took
off.
I
But
if
you
want
to
have
a
way
to
tell
a
proxy
to
put
UDP
packets
on
on
the
network
on
your
behalf,
I
think
you
can
do
a
lot
cleaner
than
this
I
mean
I,
find
this
whole
thing
very
complex
and
with
very
little
architectural
thinking
behind
it,
and
that
makes
me
sad,
probably
there's
a
use
case
in
there
that
you
that
you
find
useful
since
you're
standing
here.
Talking
about
this,
but
I,
don't
understand
I,
but
I,
don't
see
an
architecture.
I
can
understand
inside
it.
E
B
Done
Martin
Thompson
there
was
a
lot
of
negativity
from
Harold
here,
I
I.
B
Think
a
lot
of
those
concerns
are
ones
that
we
need
to
address,
though
I'm
far
more
positive
on
this
I
think
that
the
general
idea
that
you
have
the
goals
that
you'll
be
looking
to
address
quite
fine.
The
way
that
in
which
you're
going
about
it,
gives
me
all
kinds
of
bad
feelings
and
Howard
managed
to
capture
a
lot
of
those
fairly
well.
B
Maybe
I
disagree
with
him
about
the
relative
utility
of
having
the
full
your
eye
in
a
request,
but
that's
just
a
minor
point,
I'm
sort
of
wondering
whether
or
not
this
is
turn
that
you're
looking
for
yeah
sure.
E
B
I
definitely
think
that
Lucas's
design
is
is
closer
to
to
what
we
want
in
in
that
respect,
I
think,
okay,
the
idea
that
you
have
quickly
to
some
point
and
then
you
want
to
initiate,
say
quick
again
from
that
remote
endpoint
is
an
interesting
one
and
one
that
I
think
we
should
be
examining
a
little
bit
more.
But.
E
Yeah
so
I
fully
recognized
that
this
design
is
very
different
from
the
kinds
of
of
proxy
protocols
that
that
we
normally
talk
about,
and
particularly
it
has
these
this.
This
very
strange
best
effort,
only
semantics,
where
at
almost
every
step,
there's
there's
no
clear
guarantee
about
what
you're
going
to
get
and
that
sort
of
reflects
a
pessimistic
view
of
of
connectivity
on
the
Internet.
E
So
in
terms
of
turn,
I'll
just
mention
to
you
that
turn
has
a
number
of
interesting
characteristics.
One
of
them
is
that
it
proposes
copying
all
of
the
IP
IP
flags,
basically
things
like
ecn
and
and
dscp
from
the
IP
layer
itself,
on
the
turn
link
to
the
to
the
external
link
and
vice
versa,
as
because
it
has
no
way
internally
of
representing
any
of
those
flags.
E
So
if
you
essentially
believe
that
those
things
don't
matter
that
that
IP
doesn't
have
any
attributes
other
than
addresses,
then
and
doesn't
contain
any
protocols
other
than
UDP,
then
turn
is,
is
a
very
reasonable
approach
and
I
would
be
fine
with
that.
I
think
the
question
here
you
know
this
is
a
like.
Like
the
name
says,
this
is
a
hybrid
encapsulation
for
both
IP
and
UDP
I.
Think
the
the
question
is
whether
there's
demand
beyond
the
the
baseline
of
this
bless.
Udp.
B
J
Over
quick
dock
editor,
so
I
definitely
think
being
able
to
do
and
HTV
quick
equivalent
to
connect
that
would
get
you
another
HTTP.
Quick
connection
is
something
we're
going
to
need,
assuming
this
quick
thing
takes
off,
because
currently
that's
how
you
get
a
TLS
connection,
past
epoxy
is
you
do
a
connect
and
to
say
that
people
behind
proxies
cannot
use
quick
to
do
encrypted.
Connections
out
to
the
Internet
is
kind
of
sad
now.
One
thing
I
would
point
out
on
your
architectural
slide
that
you
have
the
the
yes,
the
abstract,
layering
and
then
one
instantiation.
J
K
J
J
We
can
port
that
reasonably
simply
into
HTTP
over
quick
fine,
but
the
quick
stream
is
still
in
order.
Yes,
and
it's
going
to
have
head
of
line
blocking
I
think
you
at
least
have
a
way
out
from
the
congestion
problem
by
having
timestamps
on
it,
so
that
maybe
we
can
sidestep
that
congestion,
control
inside
congestion
control
and
you're
you're
essentially
doing
remove
congestion
control,
but
where
you
ultimately
want
is
a
feature
that
quick
doesn't
have
yet,
which
is
to
have
a
message
level
message:
semantics
inside
quick,
maybe
associated
with
the
screen.
E
H
Just
speaking
to
the
whole
congestion
control
inside
congestion
control,
now
philosophically
I
understand
the
distaste
here
but
sort
of
speaking
for
someone
who's
running
on
very
large
turn
deployment
that
I
can
in
practice.
We
actually
see
these
issues
are
not
nearly
as
bad
as
you
would
think
they
would
be,
and
that
turn
TCP
actually
works
quite
well,
especially
when
you're
using
Nagle
or
have
Nagle
disabled
on
the
extra
TCP,
Mike
and
Eamonn,
and
in
the
cases
what
it
actually
turns
out
to
be
a
problem.
H
There
are
actually
some
clever
solutions
like
you
can
have
multiple
TCP
connections
for
a
single
sort
of
remote
endpoint,
and
then
you
can
sort
of
round-robin
between
them
to
deal
with
that
in
mind.
Blocking
so
like,
we
may
find
this
kind
of
architecture
leaning
like
inelegant,
but
there
are
some
mechanisms
that
are
well
tested
and
can
actually
solve
these
problems.
L
They're
not
above
a
Microsoft
yeah
I
actually
agree
with
Justin
that
these
things
are
very
fixable
with
the
appropriate
communication
between
the
layers,
but
I
actually
was
come
up
here
to
try
to
cancel
out
most
of
Harold's
negativity
by
trying
to
say
a
lot
of
positive
things.
I
think
the
problem
you
may
have
here
is
they're.
Actually
too
many
good
problems,
you're
trying
to
solve,
and
it
may
help
to
focus
on
a
few,
certainly
I
think
the
proxy
one
is
is
definitely
very
needed.
L
So
you
could
do
that
one
and
there,
but
also
I,
won't
I
will
say
that
I'm,
not
a
lover
of
turn,
I
think
it
has
a
huge
number
of
scalability
problems
which
could
be
potentially
fixed
by
some
of
the
ideas
you
have
there.
But
that
might
be
not
saying
you
have
to
do
all
those
things
at
once,
but
maybe
if
you
focus
on
one
problem
and
then
focus
on
another
problem,
maybe
you'll
see
common
error.
L
E
E
One
clarification
question
and
then
fall
about
that,
so
it
seems
like
in
the
document
I
sort
of
read
through
it
and
it
seems
like
you're,
assuming
that
are
you
assuming
that
the
end
server
the
target
server,
which
is
sitting
behind
the
proxy,
actually
has
no
idea
of
the
hybrid
encapsulation?
Yes
yeah,
so
there's
like
I
think
the
difference
between,
for
example,
HTTP,
connects.
E
E
If
you
have
the
a
bit
ago,
back
of
it,
I
was
actually
wrong
in
that
saying
that,
but
what
I'm
gonna
say
is
that
there's
another
way
of
doing
this,
where
the
target
server
actually
also
cooperates
in
the
encapsulation
protocol,
which
is,
for
example,
IP
IP,
GRE
encapsulation,
where,
for
example,
you
can
enable
interesting
features
like
direct
server
return
with
those
dos
gains
versus
actually
rewriting
IP
addresses
when
you
go
traverse
through
the
NAT
implies,
like
you
have
to
like
correct
the
checksum
when
it
goes
through
this
NAT.
So
it
involves
a
lot
of
performance.
E
E
At
least
it
seems
like
it's
not
as
applicable
to
us
our
use
case,
because
we
would
do
IP
IP
encapsulation
when
we're
doing
it
inside
the
datacenters,
but
I
am
curious
about
which
use
case
this
is
applicable
for
so
there's
more
like
an
at,
or
is
it
more
to
replace
the
IP
IP
absolution
that
exists
right
now?
I
guess
I
would
that
this
design
more
resembles
a
net
for
sure
I
had
an
ecosystem
level.
E
I
guess
I'd
have
difficulty
imagining
how
we
would
get
to
to
a
point
where
an
end
point
servers
can
be
relied
upon
to
be
aware
and
participating.
I
guess.
My
goal
here
is
to
be
able
to
contact
at
a
minimum
any
quickserver
in
the
world,
for
example,
so
that
you
can
use
this
as
a
full-forward
proxy
for
all
of
your
web
browsing
over
quick
right.
So
in
that
case
you
would
have
a
it's
similar
to
an
HTTP
proxy
at
that.
O
O
And
if
you're
really
talking
about
it
in
HTTP
only
turns
I
say
we
ditch
fast
you
to
HTTP
bits
and
then,
if,
in
fact,
you
care
about
being
able
to
use
this
over
something
other
than
quick,
then
we
dispatch
you
back
over
to
transport
to
say,
you're,
a
substrate
to
transport,
so
I
think
there
are
kind
of
three
different
potential
scopes
for
this,
and
the
dispatch
answer
is
different
depending
on
scope.
So
it
would
be
really
useful
if
you
could
describe
which
one
you
ideally
want
me.
E
P
Brilliant
yeah
Ted
raises
some
really
great
questions
and
points
there.
I'd
say
some
of
those
aspects
have
been
touched
on
in
the
in
the
draft
I
put
together,
which
is
using.
It
is
framed
in
terms
of
HTTP
initial
initialization
of
network
tunneling,
so
we
we
use
HTTP
as
a
departure
point,
but
don't
necessarily
use
something
like
HTTP
over
quick
as
this
substrate
for
the
tunneling
it
could,
but
it
doesn't
need
to
be
so.
P
Many
of
these
aspects
have
been
collected
into
that
ID
in
terms
of
design
considerations,
and
we
welcome
further
input
I'll
be
presenting
that,
along
with
some
more
explanatory,
slides
around
some
of
the
property
models
at
tomorrow's
HTTP
Biz
session.
So
if
there's
any
further
comments,
I'd
really
welcome
people
to
come
there
and
continue
the
discussion.
A
So
look
I
was
talking
to
Charles
a
second
ago.
We
were
just
you
know,
trying
to
figure
out.
How
do
we
move
forward
from
here?
So
so
here's,
here's,
here's
our
rough
straw,
man
from
overworking
garden.
Okay,
there's
quite
a
bit
interest
in
this
there's
a
lot
of
issues.
There's
questions
about
what
the
scope
is,
what
the
problem
would
we
adapt
existing
protocols
would
make
a
new
protocol.
A
How
would
this
work
with
other
things,
even
questions
and
whenever
we
end
up
in
one
of
these
sort
of
proxy
tunnel
type
protocols,
there's
always
questions
about
whether
it's
transport,
whether
it's
art,
how
that
works?
So
it
seems
to
us
that
we're
at
the
point
where
we
need
some
discussion
on
the
list
focused
on
what
the
big
level
architecture
is,
what
use
cases
we're
trying
to
get?
A
What
that,
what
the
big
direction
is
and
and
dig
into
this
just
a
little
bit
more
on
the
list
and
peel
the
next
layer
of
the
onion
and
have
something
a
bit
more
specific
before
we
can
really
dispatch
it,
and
it
seems
that
the
dispatch
list
is
as
reasonable
as
any
place
to
go.
Do
this
right
now,
this
is
not
obviously
that
it
should
be
in
transport
or
anything,
and
it's
gonna
overlap
to
coordinate
with
people
and,
as
it
becomes
clearer,
it'll
be
we'll
figure
that
out,
but
it
doesn't
quite
seem
ready
to
dispatch.
A
Yet
does
this
seem
like
a
reasonable
path
forward?
Anyone
want
to
speak
against
this
or
suggest
something
else.
Okay,
a
DAT
is
okay
with
that
good.
Okay,
so
I
know
that
sort
of
seems
like
unconcluded
like
ya,
keep
discussing
it
do
more
work.
Thank
you
for
all
the
good
work.
You've
done
almost
likely
kill
you
in
the
morning,
but
like
I,
really
think
that
this
is
that
there's
a
lot
of
pain
over
our
current
things
and
the
quick
stuff
has
sort
of
pushed
it
to
the
breaking
point.
A
A
H
You
can
do
it
too,
if
you
want
to
I'm
gonna
speak
to
the
first
one
so
right
after
lunch
today
we're
going
to
have
a
ball
talking
about
how
the
IETF
handles
internationalization
review
and
considerations
in
documents
right
now.
We
don't
really
have
any
formalized
process
around
this,
and
it's
it's
been
raised
that
it
would
be
really
beneficial
to
have
some
sort
of
additional
supervision
around
how
we
handle
these.
H
H
B
H
Q
Humming
everybody,
my
name,
is
dawn
immunizing
and
walking
is
the
project
which
aims
to
do
optimistic
encryption
privacy
by
default,
and
we
have
submitted
five
drafts,
which
means
of
three
more
than
last
time
like
okay,
you
know.
Well,
we
have
submitted
five
drafts
all
to
get
on.
There
are
three
more
than
last
time
and
as
I
15
minutes,
I
can
only
go
shortly
into
the
content
of
these
drafts.
Q
Well,
in
short,
it
is
you
have
several
building
blocks
that
already
exist:
okay,
papé
architecture,
several
building
blocks-
some
of
them
are
already
mostly
documented
in
RFC
s,
and
we
are
intending
to
use
this
already.
Existing
building
blocks
from
the
RCS
some
pieces
are
missing
or
incomplete,
and
these
are
the
pieces
you
are
focusing
on,
like
filling
the
gaps
that
we
can
make
pretty
easy
privacy
and
email
encryption.
What
list
is
my
default,
so
this
is
one
of
the
new
slides
last
meeting.
Q
If
we
trying
to
show
you
the
message
flow
in
a
simplified
way,
so
what
happens?
First,
whenever
you
start
up
your
client
and
you
have
no
key,
then
the
client
will
automatically
generate
the
key
pair
and
if
you
want,
then
you
have
a
privacy
status
towards
the
wall
new
towards
every
tier.
You
want
to
send
messages
to
and
this
example,
we
have
a
privacy
status
off
of
B
of
the
channel
to
B,
which
means
unencrypted,
because
we
do
not
have
any
public
key.
Then
you
send
the
first
message.
Q
This
message
cannot
be
encrypted
because
you
don't
have
any
key,
but
what
we
do
we
add
to
this
message
to
your
public
key,
so
that
the
other
party
has
the
public
key.
So
what
you
see
now
happening
is
that
the
soonest
message
is
received
at
the
B
party.
It
will
import
its
publicly
and
from
that
moment,
on
the
channel
to
a
is
encrypted.
This
happens
all
automatically
we
doesn't
have
to
like
take
the
key
out
the
rights
on
the
pitch.
Q
He
GP
aired
and
this
kind
of
stuff
it's
just
done
automatically
in
the
client
and
from
that
moment
P
sent
a
message
back
and
all
the
messages
are
encrypted
automatically
and
applied.
This
means
now
also
the
other
side
is
an
encrypted
privacy
status.
So,
whenever
a
sent
message
to
B,
they
are
encrypted
to
prevent
men
in
the
middle
attacks
or,
like
a
higher
degree
of
security,
also
need
like
establish
the
trust
relationship
between
two
part.
So
this
is
kind
of
something
that
cannot
be
fully
optimized
because
trust
you
cannot
want
to
take
lick
away
totally.
Q
So
this
is
like,
in
short,
what
it
is
about
and
now
I'm
going
towards
the
drafts
that
we
wrote.
So
this
is
one
of
the
new
drafts.
It's
basically
defining
the
whole
procedures
for
email
to
basically
find
the
missing
pieces
for
email
and
the
motivation
for
this,
as
I
mentioned,
that
the
current
systems
do
not
encrypt
all
privacy,
sensitive
information,
current
systems
still
live.
Subject:
unencrypted,
for
example,
there
are
also
other
header
fields
that
need
to
be
more
careful
regarding
to
encryption.
Q
The
rain
news
cases
automatically
encrypt
emails
in
opportunistic
encryption
scenarios,
as
I
just
showed
on
the
slide.
Before
did
we
define
here
some
new
message
formats
for
privacy
integrity
and
also
like
how
this
is
automatic
heat
generation,
distribution
box?
That
I
just
explained
you
in
the
last
slide
and
here
just
in
brief
how
one
of
these
message
from
arts
works
basically
sees
encapsulation
of
the
email
of
the
original
email
into
the
encrypted
email.
Q
So
we
have
the
auto
message
that
contains
only
what
is
really
needed
and
removes
all
the
privacy
sensitive,
sensitive
information.
Then
we
have
the
image
which
contains
everything,
but
this
is
encrypted
in
the
inner
message
we
have
directional
headers
and
the
content
and
the
public
key,
and
all
that
that
outer
message
looks
like
a
father
to
me
with
some
encrypted
content.
Q
Then,
for
this
all
to
work,
we
have
made
a
draft
that
defines
the
rating
states,
so
the
goal
is
that
it
is
easy,
understandable
to
the
eurozone.
What
is
the
privacy
state
is
to
not
use
on
like
these
colors
I
showed
you
in
this
flow
diagram
before
so
that
the
user
sees
immediately.
Okay,
emails
issues
are
encrypted
or
emails
is
also
already
authenticated,
or
the
user
is
authenticated
to
receive
emails
from
you.
Q
The
motivation
is
that
to
reveal
the
prey
privacy,
stateless
to
do
zone
main
use
case,
assist
presentation
of
the
status
of
a
user,
but
also
the
status
of
the
message,
just
for
example,
the
first
message
is
never
encrypted,
so
this
one
is
then
like
show
me
in
a
different
color
than
all
the
following
messages.
There
are
some
other
cases
where
there
can
be
differences
between
state
communication
status
to
the
user,
end
of
a
message
of
each
message.
Q
So
the
most
method
we
are
defining
here,
different
privacy
ratings,
and
we
met
this
privacy
ratings
to
a
traffic
light,
color
semantics.
So
if
it's
authenticated
and
encrypted
it
will
be
green
as
I
showed
in
this
last
night,
and
if
it's
just
encrypted
it
will
be
yellow.
And
if
there
are
something
wrong
like
breach
of
a
key
or
something,
then
we'll.
G
Q
So
what
actually
happens
is
that
I
explained
it
all
right
before
we
combine
the
fingerprints
with
an
excel
function
and
then
we
met
that
to
the
trust
routes.
Explain
you
the
transports
in
the
next
slide,
then
you
compare
these
trust
roads
or
the
fold
line,
or
some
other
alternative
channel
and
update
it,
letting
ruff
join
shop.
It's
the
end
check
draft,
then
the
trust
words
draft.
It's
kind
of
an
eye
on
a
registry
definition
draft,
because
we
need
trust.
Q
Q
So
this
is
the
big
picture
we
have
feel
like
for
areas.
We
have
the
call
stuff
that
is
in
green
if
the
trust
will
change
Shaikh,
authentication
stuff,
that
is
here
in
fuchsia
color.
Another
area
is
the
applications
like
email
or
XMPP
and
for
email.
We
also
intend
to
make
a
mapping
for
s/mime.
Then
there's
an
area
I
haven't
been
talking
about.
Yet
it's
the
area
of
synchronization
of
of
keys.
Q
In
case
you
have
multiple
devices.
You
have
one
on
your
mobile
phone,
one
on
your
computer,
one
on
your
pet
tablet,
so
all
these
private
keys
can
be
synced
to
devices
so
that
you
can
actually
also
decrypt
the
message
that
has
been
encrypted
with
a
private
key
like
with
the
public
key
from
the
auto
device.
Q
Q
Q
You
want
to
make
it
the
best,
buy,
based
message
formats
if
I'm
missing
your
ice
Cream's
as
I
mention
before
Diana
registry
and
also
the
private
keys
in
conversation,
then
we
discussed
with
the
Chelsea
intellect
that
the
dispatch
working
group
is
the
best
way
to
discuss
this
for
the
time
being.
So
whenever
you
have
questions
or
comments
use
the
dispatch
list.
If
you
want
to
get
the
more
like
in
touch
with
us,
we
have
an
IRC
channel,
we've,
read
forums
and
see
our
email
addresses.
You
would
say
your
questions.
K
S
R
Put
that
into
business
environments,
web
security,
and
they
also
talk
with
companies
with
exactly
this
issues-
that
they
want
to
probably
do
worse,
Varys
protection
or
to
ensure
that
certain
information
doesn't
leave
the
company.
So
for
such
cases
you
can
of
course
two
key
escrow
inside
the
company
or
when
it
comes
to
archiving.
R
You
can
also
there's
also
its
a
general
draft
somehow
mentioned,
there's
also
a
trusted
server
mode
where
you
can
save
your
messages
unencrypted
so
that
you
can,
you
know,
read
them
without
having
keys,
so
there
are
different
methods
how
you
can
deal
with
that?
Of
course,
you
need
to
trust
you
at
least
your
own
infrastructure
in
the
end.
Otherwise
it's
for
nothing
all
this
encryption
things,
so
the
project
focuses
paid
basically
on
on
targeting
mass
surveillance.
R
K
T
I'm
Keith
Moore
I
want
to
commend
you
for
taking
this
approach
in
looking
at
it,
and
and
I
appreciate
what
you're
trying
to
do
here.
It
appears
that
one
of
your
assumptions
is
that
the
easiest
thing
to
to
the
most
malleable
piece
or
the
place
that
you
can
make
the
change
to
implement
this
is
in
the
user
agents
and
not
in
say
any
of
the
structure
I'm
a
bit
dubious
of
that
assumption,
just
because
history
seems
to
say
that
there's
not
a
lot
of
incentive
to
improve
user
agents.
T
The
other
thing
that
I
would
take
serious
reservations
with
is
the
idea
that
it's
okay
to
have
devices
exchange
private
keys
with
one
another
and
I
want
to
really
caution
against
the
assumption
that
this
acts
on
my
behalf,
in
any
respect,
because
what
I
have
found
personally
is
that
this
is
a
huge
security
hole.
This
is
dangerous.
This
thing
has
entirely
too
much
information
about
me.
It
is
too
easily
compromised,
and
so
I
will
never
trust
anything
that
expects
this
thing
to
exchange
its
private
credentials
with
other
devices.
That
is
a
non-starter.
T
G
S
H
S
What's
going
on
with
this
kind
of
mechanism,
the
user
experience
for
when
the
user
has
a
client
that
doesn't
support
this
is
miserable
I,
think
the
user
just
gets
a
blob
in
their
email
that
says
PEP,
and
they
have
no
idea
who
it's
from
what
the
subject
is
how
to
find
out
how
to
fix
this
issue
so
I'm
concerned
about
that
and
go
ahead
and
respond
to
that,
while
I
think
about
the
cycles.
If.
Q
R
R
S
S
S
G
Gondwana
I
we
talked
a
little
bit
yesterday,
so
you
know
a
lot
of
my
concerns
about
this.
That
email
is
something
that
is
an
archive
for
a
long
period
of
time
and
that
key
management,
it's
easier
to
hand
wave
key
management,
but
key
management
is
a
real
issue.
Assuming
of
working
PKI
doesn't
mean,
doesn't
scale
assume
devices
are
safe,
doesn't
scale
you've,
given
a
lot
of
ideas
that
there
might
be
tears
crowd.
There
may
be
different
people
having
different
attitudes
for
how
how
secure
they
believe
their
devices
are,
etc.
G
It
feels
like
there's
a
lot
of
complexity
in
a
lot
of
work,
for
the
users
involved
still
for
a
easy
privacy
at
a
lot
of
decisions
that
people
just
don't
make
as
soon
as
you
start
giving
lots
of
different
options
and
lots
of
different
ways
of
looking
at
things.
People
won't
use
them
because
it
gets
too
complex.
So
I
would
be
concerned
about
having
a
lot
of
different
ways
to
interact
with
this,
because
the
default
will
either
be
insecure
or
unusable.
I
A
S
I
Very
commendable
that
you
want
to
do
this
and
very
nice
that,
if
that
you
can
do
paint
my
mailbox
yellow
with
it,
if
you
succeed,
and
but
my
big
worry
about
this
architecture
is
actually
private
key
exchange
because
the
way
of
setup
we
assuming
that
each
identity
as
one
Pratt
has
one
primary
private
key
that
all
the
messages
are
encrypted
to
and
that
all
the
devices
share
access
to
this
private
key.
So
how
do
you
handle
the
revocation
of
permission
for
the
device.
R
I
R
R
With
your
ideas,
I
mean
the
main
intention
here
for
now
is
we
want
to
encrypt
more
messages,
because
it's
just
like
we
have
mass
surveillance
and
nobody's
doing
I
mean
there's
no,
no
easy
solutions
for
yeah,
let's
say
normal
people
and
yeah,
of
course,
if
we
can
do
it
better.
So
that's
why
we
are
also
here.
U
A
A
N
N
If
you
have
a
mechanism
that
will
work
some
of
the
time,
but
if
they're
behind
in
that,
if
they're
behind
a
DNS
that
doesn't
give
you
the
full
range
of
records,
if
they're
back
in
a
scripting
interface,
that
only
it
allows
you
to
resolve,
hosts
and
names
that
doesn't
work.
So
this
has
to
work
absolutely
a
hundred
percent
of
the
time
in
the
internet
as
it
is
deployed
today.
So
you
can
suggest
a
better
way,
a
more
efficient
way
of
it.
Working
for
when
they've
got
a
capable
internet,
but
you
can't
say:
well.
N
N
So
ok,
so
there
is
already
a
document
out
there
that
constrains
about
95%
of
the
solution.
Space
and
that's
RSC
sent
six
seven
three
six
three,
which
describes
service
discovery
using
SRB
and
txt
records,
and
basically
each
time
I
come
to
do
this
I
end
up
writing
a
piece
of
document
that
says:
ok!
This
is
how
you
do
it.
N
You
go
to
RFC
670
63,
and
this
is
what
that
spec
applied
to
this
problem
means
as
far
as
I'm
concerned,
and
the
thing
is
that
each
time
I
do
it
in
a
working
group
environment,
it's
kind
of
like
oh
well:
do
we
want
to
use
SRV
records?
Do
we
want
to
use
text
records?
Oh,
we
could
do
it
this
way.
We
could
do
it
that
way,
and
that
sounds
great
until
you
realize
that
this
is
a
service
discovery
mechanism
I'd
be
really
good.
N
So
in
67-63,
you've
got
SRV
records
and
you've
got
technical
that
do
the
basic
service
discovery
and
then
what
the
ability
to
graft
on
txt
records
that
describe
the
service
and
yes,
the
prefix
records,
and
yes,
some
folk
in
the
dns
for
world
have
not
yet
got
fully
on
board
with
prefix
records,
but
that's
water
on
them
and
the
Bradys
just
happened.
Sorry,
what
you
don't
get
from
67-63
is
a
statement
of
well
what
happens
if
you're
in
a
scripting
language
that
doesn't
support
arbitrary
retrieval
of
retrieval
of
our
arbitrary
DNS
records?
N
What
do
you
do
if
you're
behind
and
that
or
you
behind
some
sort
of
firewall,
that
is
filtering
out
records
that
doesn't
know,
and
you
turn
out
that
yes,
99%
of
the
time
the
internet
behaves
but
there's
still
enough
times
it
doesn't
so
the
proposed
approach
is
basically
to
follow.
What's
there
and
clean
it
up
a
bit
and
explain
it
in
the
context
of
if
your
problem
is
discovery
of
a
web
service?
This
is
how
you
apply
that
other
approach.
N
So
we
are
using
the
SRV
and
TXE
records
as
the
preferred
mechanism
for
discovery
and
where
there's
a
slight
difference
is
that
well,
we
still
use
SRV
records
to
to
obtain
the
set
of
hosts
that
implement
this
service.
We
have
the
ability
to
use
a
txt
record
to
describe
a
service.
You
know
that
is
every
host
that
supports
that
service.
N
So
here's
an
example,
so
we've
got
alice
at
example.com
and
we've
got
a
bunch
of
records
here
that
are
describing
various
pieces.
So
we've
got
two
hosts
to
supporting
the
mathematical
mesh
protocol,
and
so
you
look
at
the
top.
So
the
first
two
are
the
SRV
records
that
are
basically
mapping
to
two
hosts
and
then
underneath
that
we've
got
a
cname
record.
That
says:
ok,
if
you
try
to
resolve
example.com,
here's
a
cname
to
go
to
host
3
and
then,
if
you
look
down
here,
we've
got
post,
1
and
host
two.
N
Those
are
the
a
records
to
be
viewed
by
the
SRV
host.
One
doesn't
have
now
there's
a
decoration
here,
there's
a
txt
record
that
says
all
the
hosts
support
versions,
1
through
2
point
not,
and
then
here
we
have
at
the
bottom
here
on
host
2.
We
have
a
decoration
that
says:
here's
the
endpoint
to
use
for
this
particular
host
and
then
at
the
bottom.
N
N
But
if
people
just
want
to
do
the
very
simple
stuff,
that's
specified
in
the
draft.
Well,
it
is
little
more
than
a
an
increment
on
an
existing
specification
and
just
takes
that
specification
says
here's
how
to
do
it
for
web
services.
So
in
that
case,
maybe
an
ad
sponsor
draft
if
the
adsr
interested.
So
that's
it
can't.
A
V
V
Okay,
RFC
six,
four
one,
five
host
meta,
which
is
the
reason
Aaron
joined
me
to
do
the
well-known
registry.
Originally
the
big
difference
between
what
you're,
proposing
I
think
in
a
host
Maydays
host
meta
uses,
link
relation
names
as
the
keys
into
the
services
rather
than
service
names
and,
and
so
I
think.
Maybe
one
thing
that
would
be
interesting
to
do
would
be
to
dig
into
what
properties
do
you
want
to
get
out
of
reusing
service
names
rather
than
something
else
like
relations,
because
you
know
using
SRV
is
not
very
web.
V
Like
link
relations
are
arguably
much
more
web
like
and
if
you
want
to
use
this
for
web
services
now,
the
question
is
what
what
kind
of
properties
do
want
to
get
out
of
using
them?
So
free
we're
having
a
session
tomorrow
about
SRV
and
HTTP
and
how
they
don't
terribly
work
very
well.
So
that's
I
guess
where
I'd
explore
as
to
why
you're
taking
this
particular
path.
There,
okay,.
V
N
I
mean
the
thing
is:
I
mean
yeah
I've
done
web
services,
I
wrote
the
first
thing
that
became
a
web
services,
standard
I,
think
X
kms,
so
I've
been
doing
it
a
long
time
and
I
said
been
going
on.
I've
been
thinking
well.
This
has
really
got
less
and
less
to
do
with
the
web,
and
you
know
I'm
wondering
if
maybe
all
the
folk
we're
really
ever
trying
to
do
was
to
get
around
firewalls
and.
N
So
for
a
lot
of
them,
I
mean
like
yes,
I
mean
like
yes,
it's
not
looking
terribly
webby
I'm,
not
sure
whether
that
is
a
bug
or
a
feature
in
that.
You
know
most
of
the
time
when
I'm
writing
a
web
service.
The
first
thing
I,
do
is
to
say
no
cash
yeah
because
disable
all
the
stuff,
that's
in
HTTP
and
then
basically
I've
ended
up
with
a
TCP
stream.
V
N
I
mean
think
the
thing
is
that
this
is
about
how
do
I
get
to
that
webby
world.
This
is
about
how
do
I
do
that
initial
bootstrap.
That
tells
me
whether
I'm
going
to
go
over
AC
P
HP
over
quick,
if
I'm
going
to
what
type
of
encoding,
which
type
of
version
all
that
stuff
that
this
is
stuff,
that
the
DNS
should
be
providing,
because
that's
really
what
the
DNS
is
about.
V
Guess
at
the
risk
of
angering
another
section
of
the
community
to
me
the
underlying
question,
there
is:
how
much
do
we
want
to
base
what
we're
doing
on
the
DNS
architecture
alee
like
do
you
want
to
be
continued
to
be
extending
DNS
or
is
it
something
where
we're
like?
Okay,
let's
keep
that
in
a
box,
because
it's
got
its
own
issues
well,
I.
N
G
Braun
gondwana
I
had
many
of
the
same
questions.
If
you
go
back
a
couple
of
slides
to
where
you've
got
yep
your
example.
Sorry,
there
I
noticed
you've
got
a
version
with
a
specification
in
is
that
supposed
to
be
machine,
readable
or
human
readable?
Actually,
I
copied
that
out
of
another
yeah,
because
no.
N
G
N
G
That
specification
yeah,
because
certainly
if
you're
trying
to
select
yeah,
which
of
the
which
of
the
hosts
supports
a
particular
version
of
the
API
or
a
particular,
we
had
an
example
of
quick
versus
JSON
or
whatever
generally
with
this
kind
of
service.
What
I
would
expect
is
that
the
endpoint
would
advertise
what
it
supports
in
an
accept
header,
and
you
would
then
know
what
you
could
use
to
communicate
with
it
right.
G
G
Initial
boot
strap
the
other
thing
under
stairs.
You
have
a
path
equals
slash
service
on
one
of
the
hosts
yeah.
When
you're
talking
about
restricting
standards
restricting
options,
you
give
it
an
option
there,
and
then
you
have
the
same
IP
address
for
host
3,
which
doesn't
have
that
path
equals
service.
It
feels
like,
if
you
only
got
part
of
this
information,
it
would
fail.
You
know
that.
G
K
G
N
Is
one
of
the
features
that
yeah
it
is
used
in
existing
services
that
use
this
type
of
discovery
so
and
given
that
and
the
only
time
that
I
would
think
I
would
ever
use,
it
would
be
if
I
had
wanted
to
have
one
host
I
wanted
to
have
one
particular
host
to
a
particular
version
yeah
and
just
have
that
on
a
different
URL,
because
a
different
thing
was
behind
it
that
that's
the
only
case,
I
think
I
would
ever
you
think
it
yeah.
Okay,
I
can
see
that.
F
John
I
skip
the
Florida
site
again
here
and
that's
not
back
again
yeah.
That
was
that
proposed
approach.
So
my
concern
about
helping
both
SRV
and
the
fall
back
to
that
well-known.
So
these
are
not
two
things
that
administrators
have
to
configure
and
maintain
and
what
happens
when
they're
out
of
sync,
and
so
what
I'm
so
forth
and
you've
confirmed
that
you
have
to
have
the
fallback
all
the
time
anyway.
F
N
N
In
terms
of
how
you
are
we're
actually
going
to
set
something
up,
I
mean
like
yep
the
cases
where
you
would
pro.
As
far
as
I'm
concerned,
yeah
I
have
hosts
that
serve
my
web
service.
Mm-Hmm
I
have
hope
so
my
website
I
have
posts
that
do
web
services.
Okay
and
the
two
are
completely
separate
and
always
will
be,
and
so
the
fallback
piece
is
probably
always
going
to
end
up
as
being
some
sort
of
redirect
anyway.
N
F
F
N
But
then
you
can't
use
the
ability
to
talk
about
different
version
numbers
different
content
types
and
do
that
intelligent
host
selection,
which
people
who
have
been
doing
the
six.
You
know
the
existing
services
that
use
SRB
and
txt
for
selection
are
actually
making
use
of
I.
Think
you
could
still.
It
might
be
able
to
get
a
little
more
onset,
so
yeah
yeah.
It
is
an
option.
N
N
H
Adam
Roach,
yes,
so
in
particular,
and
I
haven't
had
time
to
look
at
the
rest
of
the
details.
But
looking
at
just
on
slides
here,
I
have
some
concerns
about
the
way
it's
using
DNS,
see
names
and
I.
Think
that
would
need
to
go
in
front
of
people
with
a
lot
more
DNS
knowledge
than
is
present
in
apps.
Okay,.
H
N
A
H
I
mean
if
people
in
the
room
how
feedback
in
the
draft
I
think
dispatch
is
probably
like,
like
apps
level
feedback
dispatch
is
probably
a
reasonable
place
to
do
that.
I
think
in
terms
of
driving
it
forward
I'd
like
to
see
the
DNS.
Can
you
need
to
get
involved
before
we
try
to
do
a
whole
lot
of
you
know
more
churning
on
improving
the
document.
H
N
N
H
I,
it's
so
I
mean
I,
think
I'm
sort
of
proxying
concern
here,
but
it's
like
when
I
look
at
this
is
like
you've
taken
a
large
portion
of
the
DNS
basin
started
squatting
on
it's
like
you're
importing
the
entire
service
registry,
as
as
host
names
effectively,
which
seems
problematic,
so
I
think
that
that
probably
needs
a
little
bit
more
thinking
behind
that
yeah.
But
again
it's
more
of
a
you
know.
We
would
need
a
DNS.
You
need
to
give
us
feedback
on
that.
Then
I'm,
not
an
expert
on
it
right,
yeah.
N
H
A
D
Name
is
Andrew,
Sullivan
I,
don't
know
if
I'm
a
DNS
guy,
but
I
will
point
out
that
in
DNS
off
there
is
currently
just
finishing
or
something
like
that:
an
adder
leaf
document
that
is
about
this
entire
registry
and
how
to
cope
with
it
and
so
on
so
there
that
this
is
a
long
festering
problem.
I,
don't
know
that
that
document
gets
it
like
makes
it
any
better,
but
it
documents
how
it
works
and
and
I
think
it's
a
known
problem
that
is
is
assault.
That's
is
ever
gonna
be
anyway.
H
Adam
Roach
again
so
yeah
thanks
for
bringing
it
up
that
actually
pertains
pretty
well
to
the
like
the
underscore
prefix
stuff,
I,
don't
and
I'm
talking
to
Andrew
here
I,
unless
I've
missed
something
that
doesn't
actually
talk
about
using
like
non
underscore
labels
on
like
C
names
or
a
records.
Writing
like
that
right,
okay,
but
it
was
the
latter
thing
that
I
was
more
concerned
about
here.
D
So
this
is
the
general
problem,
though,
of
the
of
the
entire
txt
record
challenge.
This
is
the
long-standing
problem,
and
the
basic
problem
is
that
if
you
have
one
of
those
kinds
of
things
and
somebody
else
might
come
along
and
register
another
name
in
there,
then
you're
hosed-
and
this
has
been
like
the
the
constant
hosing
that
we
had.
We
have
this
problem
with
SPF
we've
had
this
problem
with,
you
know
dozens
of
text
records.
We
have
this
problem
today
with
every
mail
service
in
the
world.
D
Who
tells
you
what
this
GXT
record
with
this
key
at
the
apex
of
your
zone
and
what
happens
is
you've
got
like
500
txt
records
at
the
apex
of
your
zone
and
it's
an
immediate
DDoS
problem.
There
is
no
way
to
solve
this
generally
without
some
kind
of
registry.
If
you
want
my
personal
opinion,
the
DNS
is
like
well
overloaded
at
this
point,
but
you
know
it's
it's
the
way
that
people
are
gonna.
Do
it
because
that's
the
database,
we
got
yeah.
A
W
V
Mentioned
it
before
we're
having
a
little
side
meeting
on
Tuesday
about
HTTP
in
SRV,
because
some
people
keep
on
saying
why
doesn't
web?
Why
don't
web
browsers
support
SRV,
it's
so
easy
and
other
people
say
you're
insane,
so
we're
gonna
get
them
together
and
have
a
nice
chat
and
see
if
we
can't
at
least
kick
that
ball
down
the
road
a
little
bit.