►
From YouTube: IETF102-DPRIVE-20180718-1330
Description
DPRIVE meeting session at IETF102
2018/07/18 1330
https://datatracker.ietf.org/meeting/102/proceedings/
A
Afternoon,
everyone
welcome
to
Dina's
privacy
I
promise.
This
will
be
if
you
were
endianness
off
this
morning.
This
will
be
a
much
calmer
sort
of
meeting.
So
so
just
yeah
heads
up
mr.
Velas.
If
you
can
grab
the
door
at
some
point,
I
would
love
you
a
lot
for
it,
so
that
would
be
oh,
so
much
Susan's
got
it.
Thank
you,
though,
welcome
I'm
Tim,
that's
Brian
Carrie's,
our
a
great
area
director,
Dan
York,
is
Jabbar
scribing
and
now
he's
fully
caffeinated
and
he's
in
great
shape
and
Chris
would
raise
your
hand.
Mr.
A
Chris
and
I
know
you're.
Here
you
would
take
minutes.
I,
don't
see
you
Chris,
okay,
so
if
Chris,
doesn't
we
don't
see?
Kristin
would
probably
some
help
on
the
minutes
may
be
good,
but
it
should
be
a
fairly
light
agenda.
You
all
know
the
note.
Well,
this
is
pretty
good.
This
is
actually
the
updated
text.
I
made
sure
I
got
the
updated
text
in
there.
So
if
somebody
approved
of
it,
there
are
blue
sheets
passing
around.
Please
fill
them
in
we
like
to
see.
A
What's
going
on,
they
gave
us
a
big
room,
so
we
did
yeah
a
very
quick
update.
We
got
a
couple
current
documents,
but
basically
there's
some
new
documents
coming
up
that
we're
going
to
kick
about,
but
the
big
thing
is.
We
have
some
new
milestones
from
the
last
working
group
meeting.
They
did
a
recharter
brian
and
terry
worked
on
some.
It
actually
went
much
simpler
than
I
expected,
but
we
have
three
three
new
milestones
about
develop
requirements
for
adding
confidentiality
to
preview,
cursive,
authoritative.
Of
course.
That's.
A
Why
we're
all
here
and
we're
looking
at
sort
of
doing
potential
solutions
for
unix
exchanges
involving
authoritative
servers,
and
we
want
to
do
some
more
collect
some
more
operational,
basically
performance
data,
we're
very
I
think
the
more
performance
data
we
collect,
the
better
we
can
sort
of
prove
to
people.
This
is
a
very
viable
technology
which
I've
barely
I'm
pretty
strongly
Oh
make
his
DNS
service
discovery.
David's
nas
he's
here,
he's
he's
currently
co-chairing
by
himself.
A
So,
if
you're
interested
in
doing
getting
involved
in
sharing
a
working
group,
it's
a
light
working
group
we've
got
a
great
area.
Director
doesn't
get
a
lot
of
mileage
good
work
and
you
should
talk
to
Terry
mandersohn
he'll
raise
his
hand.
That's
the
only
thing
you
have
to
do
today
is
raise
your
hand.
We
promised
him
a
simple,
simple,
Pleasant
meeting
so
and
I
have
to
produce
now,
so
you
promised
I
did
probably
so.
I
did
promise,
while.
B
We're
on
the
topic
david's
chasm,
we're
on
the
topic
of
dns
SD
I'd
like
to
take
30
seconds
for
a
shameless
plug.
One
of
the
things
that
were
working
on
in
DNS
SD
right
now
is
privacy.
So,
right
now,
if
you
look
at
the
multicast
traffic
on
this
network,
you
can
find
basically
everyone's
name,
which
is
not
great.
We
want
to
fix
that
problem
and
I
know
there
are
a
lot
of
people
in
the
room
who
have
a
passing
interest
in
privacy.
B
A
The
only
the
current
actually
the
only
current
document,
an
update
is
padding
policy
and
we
found
the
author.
He
was
hiding
or
something
so
Alex
he's
not
here,
but
he
showed
up
and
he's
like.
Okay,
he's
fixing
the
discusses
right
now
with
the
iesg
and
I.
Think
we're
ready,
we'll
be
ready
to
sort
of
move
this
forward
into.
You
know
ITF
last
call,
so
it
just
took
us
a
while
he
tends
his
disappear
for
periods
of
time.
So
quick
agenda
me
Brian's
good
he's
got
some
right
path.
A
A
We
always
love
these
sort
of
wacky
things
in
the
sphere
of
dkg,
I
always
say
so.
This
is
like
a
four
dkg
sort
of
meaning
and
then
we're
gonna
sort
of
lead.
A
discussion
on
recursive
Authority,
I'm
gonna
give
it
to
Brian
to
lead
most
of
that,
because
I,
basically
ranted
and
raved
all
morning
and
I
think
people
are
tired
of
listening
to
me
so
well,
I'll.
Let
Brian
have
that
kind
of
fun,
so
so
I
think
we'll
turn
it
over
to
Brian
to
talk
about
the.
If
there's
any
other
agenda
stuff
you
want.
A
C
So
what
I
did
is
I
actually
took
one
of
my
summer
interns
and
gave
her
something
to
do,
and
that
was
to
help
this
working
group
out
without
her,
knowing
it
essentially
what
we
did
is
we
took
advantage
of
the
new
capabilities
and
the
right
right.
That
was
probes
and
we
started
doing
a
measure
that
uptake
of
DNS
over
TLS.
C
So
we
managed
to
get
in
about
almost
41,000
queries.
We
hit
36
thousand
3,600
ipv4
DNS
servers.
We
did
hit
a
couple
of
ipv6
DNS
servers,
but
I
haven't
had
chance
to
go
through
that
data.
Yet
we
had
to
get
rid
of
a
lot
of
the
responses
because
they
were
all
from
private
IP
addresses,
which
kind
of
tell
us
anything,
and
so
we
essentially
got
61
servers
to
respond
over
TLS,
which
is
a
paltry
one
point:
six,
seven
percent
of
the
servers
that
we
talked
to.
C
However,
after
having
some
conversations
with
Oliver
and
and
Martin
from-from
CloudFlare
and
the
folks
at
Wright,
we
found
out
that
a
lot
of
the
bad
responses
that
we
that
we
were
getting
either
to
the
one-one-one-one
or
the
one-zero-zero-one
servers
is
basically
due
to
a
crypto
mismatch.
And
so
what
I'm
gonna
do
is
work
on
actually
go
back
and
make
sure
that
the
probes
that
we're
using
are
using
the
upgraded
open,
SSL
library.
So
those
numbers
should
go
up
by
a
fair
amount.
C
E
C
So
the
error
results
that
came
back
actually
give
us
some
indication
of
what
might
be
going
on.
We
did
get
a
fair
number
of
connection
refused
and
other
ones
were
just
connection
timeouts,
but
we
haven't.
We
haven't
generated
the
statistics
yet,
but
that's
that's
what
one
of
the
things
I
want
to
do
as
I'm
automating,
the
results
is
to
measure
not
only
what
the
what
the
success
rate
looks
like,
but
also
what
the
potential
causes
of
the
failure,
because.
E
F
Okay
hi:
this
is
general
count.
Gilmore
thanks
for
doing
this,
I
would
love
to
see
this
happen
continued
to
happen.
So
this
is
great
I'm
wondering
you
could
clarify
a
couple
of
your
of
the
details.
Can
you
go
back
a
slide
yeah
next,
one
forward:
I,
guess
that
one
yeah
so
you've,
measured,
61
DNS
servers.
How
many
of
the
ripe
probes
to
that
like
the
percentage
is
based
on
number
of
servers
identified
overall
or
saying
that
there
could
be
like
a
hundred
probes
who
all
talk
to
one
server
right.
C
F
C
Because
we're
actually
asking
for
groups
of
a
thousand
probes
we're
just
randomly
getting
assigned
probes,
one
of
the
things
that
we
want
to
do
in
order
to
address
the
SSL
mismatch
is
to
specify
which
classes
of
probes
we
want
to.
We
want
to
use,
and
so
some
of
these
numbers
are
going
to
change,
mainly
because
my
understanding
is.
Is
that
the
difference
between
the
v3
probes,
which
have
the
SSL
mismatch
and
the
v4
probes?
C
You
know
some
of
those
are
topologically
different,
so
we
might
see
different
results,
but
part
of
what
I
want
to
be
able
to
do
with
with
with
this
visualization
part,
is
see
how
much
of
the
address
space
we're
actually
measuring
and,
and
that
will
give
us
a
better
visibility
as
to
where
these
DNS
servers
might
actually
be.
Okay,.
F
C
F
But
that
there
were,
there
is,
there's
still
an
opportunity
there
to
do
this:
reach
ability
test
towards,
say,
quad,
nine
or
one
dot,
one
dot,
one
dot,
one
which,
where
we
know
that
port
853
should
be
open
and
that
a
TLS
handshake
should
be
possible,
but
that
I'm
just
clarifying
that
this
test.
This
testing
that
you've
done
here
doesn't
do
that
kind
of
reach
ability
test
from
the
right
ballast
probes.
Well,.
C
You
you
get,
you
get
an
indication
of
a
reach
ability,
because
you
either
get
it.
You
either
get
a
successful
connection
or
you
get
back
an
error,
State
right
right,
so
so
so
part
of
reason.
Why
I
know
that
that
you
know
we
have
the
problem
with
that
with
that
1.67
number
is
because
when
I
go
and
look
at
the
raw
statistics,
I
find
one
one
one
one
in
there.
A
lot
with
with
an
error
state
I
see
so.
C
F
Yeah,
so
the
one
that
interesting
thing
is
is:
is
the
network
can
allow
for
853
three
right,
that's
a
good
point,
yep
or
intercepted,
and
do
TLS
man-in-the-middle
for
taking
advantage
of
opportunistic
mode
or
whatever
like
it
would
be
nice
to
get
those
kinds
of
measurements
to
you.
So
this
is
great
work.
Thank
you
yes,
and.
E
So
I'm
going
to
talk
about
two
drafts:
I'll
start
with
the
seven
seven
six
six
biz.
It
makes
more
sense
to
try
and
explain
why
we
did
this,
so
this
was
published
three
years
ago
now
and
it
was
actually
the
first
document
that
came
out
of
deprive-
and
the
intention
was
that
this
described
the
privacy
issues
that
uses
the
DNS
have,
and
it
was
supposed
to
be
an
analysis
of
the
present
situation,
not
prescribing
any
solutions.
E
So
we
started
writing
the
new
version
and
what
we
realized
was
there's
lots
of
threats
around
using
encrypted
protocols
that
weren't
described
anywhere
so
I
actually
started
describing
those
threats
in
the
BCP
document
and
then
talk.
This
is
stupid.
This
isn't
the
place
for
them.
The
right
thing
to
do
is
to
go
back
to
766
beers
and
update
it
for
the
present
situation
and
put
the
threats
in
there,
the
idea
being.
We
then
have
to
companion
documents.
E
E
There's
some
text
in
there
that
describes
attacks
on
encrypted
transports,
and
there
is
it's
essentially
generic
text.
It's
about
the
problems
associated
with
using
TLS,
for
example,
but
I
couldn't
find
a
good
source
to
point
to
to
describe
those
so
I've
added
it
here.
But
if
say,
that's
one
thing
that'd
be
good
to
know.
If
people
think
that
section
is
useful,
there's
a
section
which
compares
doing
Doh
and
dot
and
the
difference
in
what
that
exposes
to
the
resolver.
E
We
talk
about
authentication
of
servers
and
what
can
go
wrong
with
that,
and
we
also
talk
about
the
potential
blocking
of
encrypted
services,
forcing
users
back
to
clear
text.
So
with
this
document
it
would
be
good
to
know
if
people
think
this
bliss
approach
is
correct
and
that
it's
right
to
update
this
document
and
if
they
do
feedback
on
anything
else,
we
should
be
putting
in
here
now,
because
things
have
changed,
should
I
keep
going
and
we'll
just
do
one
set
of
questions
at
the
end.
Unless
anybody.
G
E
E
Okay,
so
mater
main
document
we've
updated
the
recommendations
document
for
Danis
privacy
service
operators.
This
is
still
a
very
early
document.
We've
brought
it
here
to
get
initial
review,
we're
still
not
sure
where
the
long-term
home
for
this
document
will
be.
We've
also
presented
it
in
the
right,
B
cop
working
group,
so
we're
still
turning
this
document
over
trying
to
find
its
correct
structure
and
form,
and
at
the
moment
this
seems
like
the
best
forum
to
get
feedback
on
it.
So
the
document
had
two
main
goals.
E
One
was
to
try
and
pull
together
in
a
single
place,
because
the
considerations
around
operations,
policy
and
security
for
servers
operators
who
were
running
servers
that
offer
privacy
services.
The
first
version
of
the
draft
was
solely
focused
on
dots,
but
we've
started
trying
to
include
considerations
of
dough
in
this
one,
but
we
need
more
work.
E
E
So
in
the
first
version
we
have
references
to
relevant
documents,
kind
of
scattered
all
about
the
place.
So
what
we've
done
is
we've
tried
to
draw
them
all
together
and
put
them
in
an
appendix.
So
hopefully
this
will
be
a
really
useful
reference
section
for
people
who
want
to
get
to
grips
to
Dennis
privacy.
E
We
have
significantly
reframed
the
recommendation
section,
which
is
where
we
are
trying
to
say
what
operators
should
actually
do
for
the
service.
The
requests
we
got
from
the
last
presentation
was
very
much.
The
first
version
was
really
quite
prescriptive.
It
was
sat
around
a
must,
should
Mei
structure.
E
So
what
we've
done
in
this
case
is
we
try
to
make
it
more
contextualized
by
describing
a
specific
threat
and
then
what
can
be
done
to
mitigate
it
by
the
operator
and
we've
also
actually
reused.
The
approach
from
77
26,
where
we
divide
up
the
threats
into
three
places.
One
is
on
the
wire
between
the
stub
and
the
resolver.
One
is
in
the
resolver
and
then
the
other
is
upstream
outside
of
the
resolver,
and
we
think
that
actually
helps
the
structure
a
little
bit
we've.
E
We
had
a
very
much
a
placeholder
section
earlier
on
on
data
minimization,
so
we've
expanded
that
I'll
talk
about
that
later,
and
we've
also
had
an
attempt
to
compare
the
policies
of
for
large
operators
so
again
in
terms
of
the
way
we've
reframed
it.
So
each
section
now
has
a
threat
description
and
then
what
we
have
is
three
categories
of
actions.
Operators
can
take
the
first
one
is
a
direct
mitigation
and
we're
saying
that
operators
of
service
that
want
to
be
minimally
compliant
with
these
best
practices
should
do
all
the
direct
mitigations.
E
E
So
we
clearly
need
new
definition
that
ABS
endo
but
again
I
think
we're
now
realizing
we
shouldn't
just
restrict
it
to
Dawson
doe,
because
Creek
could
come
along,
so
we
probably
need
to
actually
develop
a
new
phrase
or
a
new
way
of
talking
about
servers
that
offer
one
of
a
number
of
encrypted
transports
and
what
whether
we
should
do
that
in
this
document
or
whether
that
should
sit
in
the
terminology.
Biz
is
a
question.
I
raced
on
the
mailing
list,
I'd
be
interested
to
know.
E
People
feel
strongly
one
way
or
the
other
so
I'll,
quickly,
spin
over
in
these
few
slides
the
content
that
we
now
have
and
how
it
split
up.
So
the
only
wire
section
considers
both
the
protocol
options
and
the
service
that's
offered
offered
by
the
resolver.
So
we
talked
about
what
transports
can
be
used.
We
talked
about
the
fact
that
operators
should
allow
clients
to
authenticate
how
they
should
do
their
certificate
management.
E
We
talked
about
access
to
this
data
and
there's
a
placeholder
for
cache
snooping
as
well,
because
we
think
that's
a
worthwhile
thing
to
discuss
here
for
the
data
minimization.
What
we
try
to
do
in
this
version
of
the
draft
is
actually
ideally,
we
would
have
liked
to
come
up
with
some
recommendations
or
a
small
subset
of
here
are
the
best
tools
to
do
this.
E
So
that's
all
in
an
appendix.
We
hope
that
will
mature
over
time
is
there's
some
consensus
as
to
which
of
these
techniques
are
suitable
for
DNS.
But
we
may
well
go
back
and
look
at
the
use
cases
in
more
detail
er.
We
also
look
at
the
data
sent
upstream
and
we
bundled
two
things
together
here.
One
is
what
happens
on
the
wire
upstream,
what
goes
from
the
recursive
to
the
authoritative
and
also
data
sharing,
because
we
consider
both
of
those
similar
in
that
it's
data
leaving
the
actual
server.
E
So
here
we
specify
things
like
keeno
minimization
what
to
do
with
the
dns
client
subnet
running
a
local
route.
We
talk
about
options
to
do
traffic,
obfuscation
and
then
a
bit
more
about
data
sharing
and
while
that
overlaps
a
lot
with
data
at
rest,
we
did
think
there
were
some
separate
specific
concerns
here
and
if
you
look
in
the
document,
I
meant
this.
In
my
slide,
we've
now
tried
to
create
some
easy
to
read.
Tables
of
this
is
what
all
the
operators
do
in
terms
of
both
their
policy
and
the
practice.
E
E
So
what
we
try
to
do
is
take
the
proposed
framework
for
the
document
and
apply
that
to
their
privacy
policies,
because
what
you
end
up
trying
to
do
in
assessing
what
these
operators
do.
Is
you
end
up
reading
pages
and
pages
and
pages
of
text
and
privacy
policies,
and
you
have
to
wade
through
all
and
extract
the
details
of
what
are
offering
what
you
know?
You
know
little
knobs
and
bells
and
whistles
that
they
have
so
we
tried
to
condense
that
into
some
tables,
and
it
was
kind
of
an
exercise
in
saying
well.
E
If
we
could
get
operators
to
adopt
the
framework,
how
much
easier
would
it
make
the
choice
for
users
to
just
at
a
glance
compare
between
the
operators
to
see
what
they
do?
I
will
say
that
I
am
Not
sure
that
the
tables
are
there
are
complete
or
correct.
So
we
would
appreciate
for
you
back
from
operators
to
see
if
we
got
there,
because
we're
not
lawyers,
and
we
just
had
to
wade
through
all
this
text,
but
it
did
actually
feel
quite
useful
and
some
interesting
things
dropped
out
of
it.
E
So
those
are
all
the
changes
that
we've
made
I'll
be
really
interested
to
hear.
Here's
a
good
question
who's
read
the
latest
version
of
the
draft:
okay
cool
so
of
the
people
that
have
I'd
be
interested
to
nicely
think
the
new
structure
works
and
it
addresses
the
comments
that
we've
got
on
the
earlier
versions.
It'd
be
good
to
know
if
they
think
the
new
content
is
appropriate
and,
as
I
said
before,
do
doesn't
work
and
great
want
to
continue.
They
will
need
to
put
time
into
reviewing
this.
So
that's
yep.
H
Barry
green
Baraka,
my
first
recommendation
is:
we
need
to
break
this
into
two
documents
if
you,
if
the
goal
is
to
have
a
not
a
BCP,
because
at
what
percent
deployment
you
don't
have
best
common
practices
for
operator
right,
so
you
break
down
it
first
into
an
informational
RFC.
It
says:
here's
your
guidelines
for
how
to
deploy
all
right.
So
you
focus
on
the
deployment,
the
resiliency.
It's
missing,
a
big
section
of
resiliency.
H
So
so
that's
a
section
and
I
mean
that's
a
thought
through
you
have
to
go
through
with
it
break
it
into
two
documents
where
you
say
how
do
you
handle
the
data
that
needs
to
bring
in
actually
talk
to
operators
who
are
actually
managing
the
data,
mobile
operators
and
also
the
whole
security
community?
Who
has
a
huge
key
dependency
because
the
thought
process
within
the
operator
community,
around
DNS
Prive,
is
on
the
data
handling
part
they
go
like
yay.
We
have
a
way
to
go
after
and
figure
out.
H
What's
going
on
in
IOT,
because
I
have
certificates
it
certificates,
give
me
identity
and
identity
gives
me
in
a
way
to
I,
can
start
seeing
inside
the
home
with
an
app
behind
the
net
and
start
identifying.
All
this
you
know
violated
broken
into
equipment.
So
there's
a
there's
this
always
this
post-poll
between
the
privacy
and
how
do
you
build
a
resilient
internet
and
building
and
resilient
internet
is
be
able
to
identify
the
infected
parties
and
get
every
mediation
criteria
around
that.
H
So
if
you
try
to
keep
both
of
them
together,
you'll
never
have
people
say:
I'm
BCP
compliant
right.
If
you
break
them
apart,
then
you'll
have
BCP
compliant.
You
can
take
informational,
operational
deployment
and
then
say
I'm
compliant.
This
specification
I'm
doing
my
BCPs
of
deploying
it
in
a
proper
way,
and
then
you
break
that,
apart
from
how
do
I
manage
the
data
separately,
if
you
keep
the
two
of
them
together,
you're
never
going
to
have
any
operator
say
I'm
compliant
to
this.
Okay,.
I
J
J
What
is
your
time
frame
on
this
and
the
reason
I'm
asking
is,
you
know
dough's
not
finished
so
I
know
you're,
probably
not
trying
to
get
done
before
dough,
but
one
of
the
things
that
we've
been
finding
in
the
last
few
months
is
people
go
ooh.
This
dough
thing
looks,
cool,
I
will
do
X
and
our
brains
go.
J
E
With
this
we
think
very
much,
it's
gonna
be
a
living
document
actually,
which
was
why
in
some
senses
we
were
hesitant
to
bring
it
here,
because
this
assumes
some
kind
of
process,
so
I
I
actually
think
we
will
see
huge
changes
over
the
next
year.
I
really
do
so
I,
don't
think
this
is
going
to
go
quickly.
What
I
would
like
is
a
relatively
stabilized
version
that
we
can
build
on
to
emerge
quite
soon
in
terms
of
the
structure
and
the
approach
to
writing
the
BCP
stabilized.
E
J
E
E
F
K
Dear
New,
York
Paul,
do
you
think
we're
gonna
have
weird
things
to
talk
about
in
the
DNS
working
group,
but
is
there
I,
like
this
craft
I?
Think
it's
a
it's
a
good
kind
of
document
to
have
I
personally
think
it's
great
to
have
it
here,
because
it
is
building
on
the
other
efforts
and
work
that
have
been
primarily
coming
out
of
deprived,
yes,
dough
as
well,
but
I
think
coming
out
of
here's
they're.
K
My
only
my
feedback
was
actually
that
I
felt
when
I
read
the
document
that
the
last
part
about
the
the
privacy
or
deep
Epes
parts
that
almost
felt
to
me
like
it
should
be
its
own,
separate
thing
because
it
just
it
kind
of
felt
you
have
all
of
this
implementation
guidelines
and
best
and
practices
and
things
and
then
kind
of
at
the
end.
It's
like
here,
a
page
on
by
the
way,
here's
how
to
write
it.
K
We
need
one
of
these
for
our
website
or
for
our
other
thing,
can
you
go
look
at
this
document
to
do
it
so
I
would
almost
see
it
as
a
separate
document
that
would
define
that,
because
I
also
think
that
may
be
something
that
you
could
probably
write
in
a
way
that
would
be
more
more
stable,
like
you
could
define
what
makes
a
good
DP
PPS
type
of
thing
and
have
that
there
and
then,
while
the
other
guidance
may
change
over
time,
that
may
be
fairly
static.
Okay,.
E
F
Is
Daniel
kind,
Gilmore
UCL
you
so
I
really
appreciate
the
work
on
this
document
and
I
just
want
to
disagree
with
the
folks
who
are
encouraging
you
to
split
out
the
data
management
parts
I
think
privacy
as
we're
starting
to
look
at.
It
is
a
really
difficult
and
interconnected
problem
and
I'm
not
saying
that
this
document
needs
to
solve
all
of
it
right
now.
F
But
if
we're
talking
about
giving
people
guidance
for
how
to
operate
a
privacy
preserving
service-
and
we
don't
talk
about
how
they
manage
the
data
that
they're
sitting
on
top
loads,
we
really
haven't
done.
We
really
haven't
done
the
job
and
I
say
this,
acknowledging
that
this
kind
of
work
is
I.
Think
unusual
within
the
IETF
to
encourage
people
to
like
how
do
you
run
your
server?
What
do
you
do
with
the
data
once
your
server
has
it?
F
E
I
think
one
of
the
things
we're
discovering
as
we
do
this
work
is
it
previously
means
different
things
to
different
people.
You
know,
if
you
ask,
and
also
there's
lots
of
different
perspective,
it's
on
it.
So
it's
almost
like.
We
maybe
need
to
define
what
we
mean
by
privacy.
I
mean
there's
lots
of
places.
That's
happening,
there's
lots
of
work
on
that,
but
maybe
some
of
the
confusion
here
is
that
we're
not
contextualizing
it
in
a
way
that
we
could
be
doing
so.
Maybe
that's
what
we
need
to
think
about.
M
Lorenzo
Cody
I'm
gonna
go
ahead
and
disagree
with
you
on
that
on
the
purely
pragmatic
perspective,
that,
or
rather
if
we
want
to
publish
a
document,
then
publishing
a
document
with
all
these.
Basically
data
retention
guidelines
is
gonna,
be
incredibly
hard
job
because
we're
gonna
have
to
talk
to
people
with
skillsets
that
aren't
found
in
this
room
and
we're
gonna
have
to
you
know
and
and
and
the
law
may
change
or
under
us
and
all
sorts
of
things.
M
So
in
that
sense,
if
you
split
it
up
into
two
now,
if
you
don't
ever
want
to
publish
that's
fine,
but
the
downside
of
that
is
that
we
don't
ever
have
a
best
practice
and
we
don't
ever
have
a
actual
RFC.
That
recommends
what
to
do
so.
Two
ways
about
it.
I
mean
I
like
to
have
stuff
published
so
I
would
sort
of
generally
be
on
the
side
of
splitting,
and
you
know
dkg
is
gonna.
M
N
John
Reed
Akamai
one
specific
question:
I,
like
the
like
how
you
broke
it
down
into
different
levels
of
compliance
specifically
around
EDS,
zero
or
sorry.
I
need
to
client
subnet
within
ETA
zero.
That
was
list.
One
of
the
minimal
mitigations
was
for
recursive
x'
to
honor
a
scope
of
slash
zero
and
to
not
pass
on
ACS
I
noticed
a
lot
of
the
work
so
far
seems
to
focus
on
the
large
public
cloud
providers.
What
sort
of
what's
the
plan?
N
N
These
are
the
actual
question
is
given
how
much
this
is
focused
on
public
cloud
providers.
Are
there
plans
to
incentivize
ISPs
running
their
recursive
x'
for
their
customers
to
onboard
with
this,
particularly
around
dcs?
We're
not
using
UCS
may
cause
actual
costs
for
them
versus
in
terms
of
traffic
links.
So.
E
One
I
mean
this
is
what
quad
nine
do
they
have
one
service
where
you
can
choose
to
have
ETS
go
upstream
because
you're,
you
don't
want
to
pay
the
performance
and
then
cost,
and
then
another
service,
where
you
don't
so
I
can
kind
of.
Imagine,
is
peace
offering
graded
services
now
which
one
they
make.
E
O
O
N
I
I
So
we
are
spinning
up
an
IRT
F
group
Sarah's,
one
of
the
co-chairs
of
that
which
is
for
privacy
and
has
enhancing
technologies,
and
it
might
be
a
reasonable
suggestion
for
that
group
to
take
on
a
data
anonymization
document
which
could
be
reference
and
then,
whichever
whichever
a
document
finishes,
first,
can
have
more
material.
But
that
is
one
of
the
reasons
I
thought
we
needed
that
research
group
is
because
we
don't
really
know
how
to
do.
Some
of
the
pressing
requirements
have
come
up
as
we
work
on
DNS
privacy.
I,
agree.
E
F
Just
quickly,
this
is
Daniel
can't
go
more
so
I
heard
a
couple.
People
say
something
about
the
the
data
retention
stuff
being
too
unstable
because
the
laws
would
change
out
from
under.
Thus
we
are
not
writing
a
legal
document
here
right.
We're
writing
a
document
about
how
to
preserve
the
privacy
of
the
users
of
the
DNS
privacy
provided
service,
and
so
the
the
when
I
was
advocating
that
we
keep
these
things
together.
F
Some
of
my
best
friends
are
lawyers,
but
this
is
not
a
legal
document
and
so
yeah
so
and
also
it's
a
best
current
practice
and
yes,
things
will
change,
and
so
we
should
be
fine
with
revising
the
best
current
practice
and
there's
a
lot
of
wiggle
room
available
in
the
minimal
compliance,
moderate
compliance,
maximum
compliance
framework
that
sarah
has
Specht
out
so
that,
if
somebody
is,
you
know,
upset
because
they
only
meet
minimal
compliance
in
what
area.
I
think
that
can
still
fall
under
rough
consensus.
C
F
P
A
A
Q
Randi
cool
thanks
for
the
time
this
is
a
new
draft.
The
first
author,
Annie
Edmondson,
is
not
here.
Paul
Schmidt
is
in
the
back
of
the
room.
Allison,
of
course,
is
here
we're
here
to
solicit
feedback
on
the
draft,
which
I
hope
many
of
you
have
read.
I
will
spend
some
time
summarizing
the
design
and
the
current
state
of
affairs
for
you
and
then
we'll
open
it
up
for
some
feedback.
Q
In
considering
this
work,
we
were
motivated
by
discussions
about
Nina's
privacy
that
that
had
come
up
in
various
contexts
about
who
gets
to
see
the
queries
and
the
IP
addresses
of
those
queriers
at
the
recursive
resolver
and
there's
a
lot
of
discussion
about
who
gets
to
run.
The
the
recursive
and
a
lot
of
the
the
nature
of
the
discussion
I've
been
seeing
is,
if
you
simply
change
your
your
recursive
resolver
from
your
ISP
to
some
other
third
party
than
all
as
well.
Q
So
I'm
not
gonna,
get
into
all
the
work
that
we
and
others
have
done
about.
The
risks
of
that-
and
this
is
the
DNS
privacy
working
group,
so
I
think
you
all
know
it
so
I'll
skip
that.
But
this
is
the
problem
that
we
were
motivated
to
think
about
which
was.
Could
we
remove
that
liability
entirely?
In
other
words,
rather
than
moving
the
trust
from
one
party
to
another?
Could
we
make
it
so
that
nobody
could
couple
the
query
with
the
IP
address?
Q
So
that's,
basically,
the
motivation
for
the
design
of
oblivious
DNS,
it's
different
from
some
of
the
other
things
that
have
been
discussed
on
the
mailing
list.
We
can
talk
about
those
and
others
towards
towards
the
end.
Is
there's
time
I'm
going
to
talk
to
you
today
about
the
the
design
that's
described
in
the
draft
as
I
mentioned,
the
goal
is
very
simple:
you've
got
a
query
and
a
response
and
you've
got
the
IP
address
that
issued.
Q
Q
Q
So
that
authoritative
can
see
the
DNS
query,
but
not
the
IP
address
of
the
requesting
client
asterisk
there
and
come
back
to
a
dns
client
subnet
later
on,
but
that's
basically
in
the
general
case,
the
properties
here.
So
the
recursive
sees
the
IP
address
of
the
original
query.
Obviously,
but
not
the
cue
name,
the
authoritative,
the
ODN,
authoritative,
sees
the
query,
the
cue
name
and
the
response,
but
doesn't
know
the
IP
address
that
initiated
the
query.
That's
it
okay!
So
let
me
just
talk
a
little
bit
about
mechanics.
This
is
a
familiar
picture.
Q
Q
Okay,
you
may
have
questions
about
performance
I'm
coming
to
that,
okay,
so
there's
a
key
I'm
gonna
tell
you
about
how
that
key
gets
distributed
in
a
minute
that
stub,
basically
encrypts
the
original
cue
name
under
that
key
shoves
that
encrypt
that
ciphertext
in
the
cue
name,
there's
some
great
magic
that
that
we
owe
to
Paul
Schmidt
to
getting
this
to
actually
fit
in
the
cue
name
and
details
to
come
on
that.
But
that's
basically
what
gets
passed
is
a
recursive
resolver
by
the
way.
Q
Another
thing
in
this
picture:
please
don't
take
it
literally
and
I
apologize
for
the
colors
and
the
animation
academics.
Do
that
sometimes
sorry
about
that.
The
other
thing
is
dodi.
Ns
is
for
the
purpose
of
illustration.
What
that
actually
will
be,
or
should
be,
is
still
under
consideration,
and
it
opens
a
discussion
and
Alison
may
want
to
say
something
about
that.
So
that's.
D
Q
The
purposes
of
illustration,
okay:
that
of
course
generates
the
referral
that
Oh,
DNS
authoritative.
Has
that
key?
It's
a
session
key
actually
for
this
query,
then
the
rest
of
the
picture
looks
similar,
writes
the
standard
recursive
resolution
that
were
familiar
with
the
answer
basically
then
gets
sent
back
encrypted
under
that
session.
Key
okay.
Q
Q
Okay,
how's
the
key
get
distributed.
This
is
the
way
we
do
it
right
now.
So,
basically
this,
how
does
this
I
should
say?
How
does
the
client
learn
about
a
key
foreign
authoritative
under
which
it
can
later
send
the
session
key
and
the
session
key
by
the
way
is
I
should
mention
thanks
to
Willem,
for
for
pointing
this
out.
It's
actually
past,
throwing
the
cue
name
as
well,
not
in
the
additional
section,
but
in
order
to
basically
send
generate
a
session
key
and
send
it.
Q
Client
first
has
to
know
a
public
key
of
an
authoritative,
OD
NS,
under
which
it
can
encrypt
that
session
key.
So
it
sends
some
special
query,
because
the
by
our
design
expectation,
these
authoritative
x'
will
be
any
casted
right.
The
the
process
by
which
this
discovery
happens
will
naturally
lead
the
client
to
a
nearby
recursive
and
a
nearby
Adina's
authoritative.
If
the
deployment
is
appropriately
replicated
in
any
cast.
That's
the
idea.
The
answer
comes
back
as
a
self-certifying
name.
Q
In
other
words,
the
name
is
the
public
key
and
that's
basically,
what's
used
for
the
client
to
generate
future
keys
right.
So
this
is
just
the
key
for
the
ODN
s
public
key
for
the
O
DNS
server,
under
which
the
client
generates
future
session
keys
for
the
queries.
Okay,
ma
at
that
point
already
there
a
bunch
of
changes
both
at
the
stub
and
the
authoritative
that
we've
made
in
a
prototype
implementation.
We
brought
it
to
the
hackathon.
We
got
a
lot
of
good
suggestions
about
about
both
the
design
and
implementation
I'm.
Q
Coming
to
that,
thanks
for
the
hackathon
by
the
way
great
event,
it
was
very
helpful
for
us
here's
a
summary
of
basically
the
changes
that
that
are
required.
Obviously,
the
stub
has
to
do
a
bunch
of
things
like
generate
a
session
key
encrypt
it
as
I
just
showed,
send
it
back
to
the
authoritative
augment
the
domain
in
this
funny
way.
Right
so
basically
got
to
take
the
original
cue
name
and
mangle
it
in
the
way
that
I
described.
Q
Oh
there's,
a
there's
a
as
I
mentioned
Willam
too
kindly
pointed
this
out
thirty
seconds
before
I
got
up
here.
These
session
keys
a
pendant,
it's
actually
put
in
the
cue
name,
not
in
the
additional
section.
Okay,
the
authoritative
basically
has
to
do
the
appropriate,
decryptions
and
forward
a
recursive,
basically
acts
as
a
recursive
there's
some
implications
for
caching.
We
can
get
into
that
in
the
discussion
as
well.
Okay,
so
where
are
we
there's
a
prototype
implementation
and
go?
If
you
are
interested
in
that
talk
to
us
well
share
it.
Q
Paul
is
also
here
to
be
happy
to.
He
did
a
lot
of
that.
Implementation
would
be
probably
I'm
sure
happy
to
talk
to
you
about
it,
and
we
were
fortunate
to
have
the
involvement
in
interaction
and
feedback
from
the
Nelnet
labs
team
at
the
hackathon,
to
both
have
a
look
at
this
and
figure
out
how
we
might
get
it
into
a
real
implementation.
Q
One
implementation
detail
that
we
discovered
so
as
I
mentioned.
If
you
try
shoving
these
keys
and
encrypted
and
names
into
various
records,
you
all
know,
but
you
will
also
discover
if
you
try
it
that
they
don't
often
make
it
all
the
way
through
recursive,
for
example,
don't
handle
the
additional
section
in
many
cases
because
of
the
hop-by-hop
semantics
I,
guess
it's
probably
worth
reading
the
standards
sometimes
before
you
try
these
things.
Q
This
is
where
we
basically
use
some
special
elliptic
curve
magic
that
Paul
I
think
can
be
happy
to
talk
to
you
more
about
to
get
the
keys
down
to
a
size
where
we
could
actually
fit
them
in
the
cue
name,
as
well
as
the
names
once
we
encrypt.
Obviously,
they
also
have
to
fit
in
that
cue
name
as
well.
We
can't
we're
not
putting
them
elsewhere
when
we
do
that
there
are
some
names.
Obviously
that
are
too
long
once
we
basically
do
that
and
then
append.
You
know
to
generate
the
referral.
Q
Q
There
are
failure
scenarios,
the
failure
scenario,
I
think
which
is
not
described
in
the
draft,
but
we
envision
is
that,
okay,
if
in
this
particular
implementation,
what
we
do
is
you
just
don't
get
a
DNS
if
your?
If
your
encrypted
queue
name
doesn't
fit,
but
that's
certainly
open
and
open
for
discussion.
Q
Another
thing
that
came
up
the
hackathon
on
this
was
that
currently
we're,
basically
just
using
a
you,
know,
regular
query
type,
but
another
possible
alternative
would
be
to
take
the
entire
queue
name
and
I'm.
Sorry,
the
entire
query
and
the
response
in
the
reverse
direction,
basically
to
shove
everything
into
txt
right,
and
that
has
some
advantages.
Q
One
is
you
don't
have
to
deal
with
this
problem,
but
the
other
advantage
is
that
the
queue
type
also
would
be
encrypted
in
that
case
right,
so
we're
not
encrypting
queue
type
here
and
focusing
the
hackathon
observed
that
the
queue
type
could
actually
leak
information
and
that
might
that
might
be
another
way
to
go.
There
is
a
performance
evaluation.
Q
I
was
advised
not
to
bore
you
with
graphs,
but
I'll
give
you
a
sort
of
short
takeaway,
which
is
that
the
crypto
operations
are
so
we
did
some
micro
benchmarks
and
macro
benchmarks,
the
micro
being
like
how
much
latency
is
going
to
add
to
a
single
lookup,
the
macro
being
like
okay,
if
you
load
web
pages
like
how
long
is
this
gonna
add
to
web
page
load
time?
Okay,
so
crypto
operations
are
actually
pretty
fast,
like
most
of
the
time
is
in
the
decrypt
at
the
authority
at
the
OD
NS
authoritative.
Q
But
when
you
add
everything
up,
we're
basically
talking
about
a
millisecond
and
that's
basically
with
our
you
know,
academic
prototype
implementation.
Presumably
this
could
this
could
get
a
bit
better.
So
there's
one
millisecond
there,
the
other
additional
latency
cost
that
you
pay
beyond
just
a
regular
DNS
lookup
is
the
late
in
the
network
latency
between
your
recursive
and
euro
DNS,
authoritative.
So
there's
one
additional
hop
that
I
showed
you
in
that
picture
that
that's
basically
gonna
be
additional
network
latency.
If
both
of
those
are
Annie
casts.
Q
If
both
of
those
are
co-located,
then
things
look
really
good.
If
there
are
like
200,
DNS,
authoritative
servers,
as
there
are
right
now,
then
your
mileage
will
literally
vary
depending
on
how
far
your
recursive
is
from
that
authoritative.
So
it's
certainly
to
the
advantage
to
the
performance
advantage
here,
to
replicate
these
and
and
and
put
them
as
close
to
the
local
recursive
as
as
possible
they're
a
bunch
of
practical
considerations.
I've
mentioned
some
of
these
I'll
just
but
I'll
raise
them.
Q
Q
I've
talked
about
all
the
opt
additional
record
considerations
already,
the
short
version
is
it.
Obviously
they
don't
work
because
the
hop-by-hop
semantics,
so
we
had
to
do
other
stuff.
There
is
one
thing
that
came
up
in
the
hackathon
that
the
NL
MATLAB
folks
pointed
out,
which
is
that
currently
we're
using
a
base64
encoding
for
the
encrypted
domain
and
the
key
the
drawback
to
that
is.
You
know
we
can't
use
hex
20
encoding.
Q
We
need
those,
we
need
those
bits,
that's
obviously
important,
so
an
alternative
that
we
just
that
we
were
discussing
there
was
using
base64
encoding
or
a
7-bit
option
and
I
talked
about
the
queue
type
being
a
clear
already.
That's
that's
something
else,
another
design
alternative.
We
could
consider
ok,
so
right
now
as
a
friend
anytime,
on
this
since
we're
talking
about
standard,
it's
not
implementation,
but
there
are
we
basically
an
egg
in
order
to
get
this
to
work
right
now
we
need
basically
no
e
DNS,
zero
client,
subnet
and
no
0x20.
Q
There
are
a
lot
of
open
recursive
that
actually
satisfy
that
right.
Now
we
can't
use
the
others.
Ok,
that's
it.
In
summary,
what
we
are
trying
to
do
is
better
protect
privacy
by
decoupling.
The
clients
IP
addresses
IP
addresses
from
the
queries
that
they're
issuing
making
sure
that
no
single
recursive
resolver
sees
both
of
those
we've
done.
An
implementation
performance
evaluation
that
sort
of
show
that
this
could
work.
Not
only
could
it
actually
does
work
and
I.
Q
Think
important
note
is
that
it's
it's
it's
completely
compatible
with
with
existing
internet
protocols,
who
you
know
this
can
pretty
much
operate
in
very
restrictive
environments.
We
make
no
assumptions
about
transport
requirements,
no
assumptions
about
support
for
TCP
or
TLS
or
any
of
the
like.
If
those
things
exist,
this
will
work
as
well,
but
we
don't
need
to
make
those
assumptions.
So
in
terms
of
thinking
about
this
as
an
alternative
or
a
compliment,
I
would
say
this
is
basically
a
compliment.
Q
A
Q
Actually
this
this
I
think
we
also
discussed
a
little
bit
at
the
hackathon
is
like
how
that
might
get
cooked
into
the
draft,
because,
obviously
you
don't
want
the
same
party
operating
those
at
the
same
time,
you
like
performance,
sort
of
suggest
that
they
should
be
close
together.
So
what
to
do
about
that
I
mean
there
are
certainly
data
centers,
where
that
is
possible,
but
yeah
I
think
there
are
administrative
and
other
questions.
I
mean
certainly
firing
both
of
them
up
on
AWS
cloud
services
might
not
be.
The
first
thing
to
do.
L
Is
it
compatible?
Yes,
okay
and
the
other
question
is:
don't
we
get
as
an
ISP,
basically
a
known
plaintext
Oracle
the
curse.
If
somebody
queries
for
an
a
name-
I
don't
know,
but
then
I
do
get
a
connection
in
my
net
flow
to
an
ipv4
address.
I
can
basically
infer
the
name
that
was
originally
queried.
Okay,.
Q
Q
To
the
first
part,
anyways
sure
I
mean
the
ISP
can
see
net
flow
and
things
like
that,
and
then
absolutely
they
can
try
to
make
inferences
from
that
shared
hosting
and
other
things
mitigate
that
somewhat
not
entirely,
but
this
is
the
DNS
privacy
working
group,
so
I
mean
certainly
there
are
other
concerns
we
can
try
to
deal
with
those
in
other
contexts,
but
I
don't
think
this
makes
those
attacks
more
possible
because
the
ice
P
isn't
going
to
see
the
thing
that
it
first
typically
relies
on.
Well,
let's
give
some
time
for
the.
R
Sure
Chris
krola,
interesting
idea,
I
mean
try
to
think
about
how
to
put
this
out
of
my
head,
and
it
seems
like
the
observations
here
really
is
that
the
recursive
resolver
is
that
open,
recursive
czar,
a
free
eye
miser
like
that
seems
like
their
actual
observation
here,
I
understand
that
correctly
that
everything
else
like
if
you
had
like,
if
you
had,
if
you
had
open,
kill
us
connect
boxes,
you
would
just
you
could
just
do
that
perfectly
well.
Right
sounds
about
right.
Yeah,
yeah,.
Q
R
R
Serious
problems
right.
Secondly,
why
are
you
using
EC
IES
as
opposed
to
just
rated
Hellman
key
exchange,
since
you
will
claim?
Presumably
six,
you
know
if
that's
that
way,
if
not
more
Paul,
did
you
want
to
make
a
comment
on
that?
Oh
no
I
think
I
can
get
your
back
like
69,
Pat's,
okay,
just
just
send
like
a
diffie-hellman
key,
a
diffie-hellman
key
directly
in
and
then
HKD
f
it
out
and
use
AES
GCM
protect
the
data
like,
and
you
proclaim
somebody
this.
Q
G
G
R
H
Q
Yeah,
it's
it's
it's
you
and
in
fact
I'll
reframe
it
it's
it's
a
privacy
problem,
not
not
problem.
In
this
case.
To
your
point
about
performance,
there
is
a
cost.
I
will
point
out.
One
thing
in
that
regard
is
this:
is
domain
by
domain
granularity
right.
So
if
you
have
performance
considerations
for
particular
objects
or
services
or
webpages,
then
you
don't
have
to
use
this
right
there.
You
know
this.
You
can
serve
objects
through
this
all
for
only
the
domain
names
that
you'd
like
to
now.
Q
H
Dns
client
subnet
with
it
say:
oh
he's,
Akamai
I'm,
not
speed.
Well,
how
can
I
talk
about
what's
going
on
in
a
mobile
environment
as
we
deploy
for
G+
and
5g
right?
The
dynamics
there,
you
know,
is
independent
with
it
and
there's
a
DNS
resolution,
speed
criteria
of
what's
going
on
with
this.
That
I
think
we
have
a
Mac
big
disconnect
between
what's
happening
here,
know
UTF
world.
What's
going
on
with
this
that
everybody's
using
right,
so
this
is
just
you
know:
throw
off
the
Akamai.
H
T
Food
yeah
thanks
for
bringing
this
I,
think
it's
very
interesting.
Two
quick
questions:
I
miss
apologize,
I
missed
the
first
one
regards
the
threat
model.
Are
you
at
all
concerned
that
this
authoritative,
Oh,
DNS
server,
effectively
turns
into
a
central
point
of
failure
for
all
your
DNS
queries,
a
Mike?
If
you
were
to
compromise,
calm
or
any
other
top
of
any
other
authoritative
route
could
still
get
to
others?
Presumably,
but
if
you
happen
to
shut
off
the
Oh
DNS
resolver
everything's
dead,
it's.
Q
A
concern
so
I
mean
I
think.
Basically,
we
can
think
about
resilience
in
in
terms
of
you
know,
it
doesn't
have
to
be
one
name
or
you
know,
name
or
achieved
it.
So
this
standard,
DNS
resilience
techniques
could
work
here,
but
it's
it's
actually
a
real
concern.
Like
said,
I
mean
something
that
that
I
really.
Q
T
Q
So
you
basically
loot
you
you,
the
the
caching
benefits,
basically
move
from
the
recursive
resolver
to
the
ODN
Authority,
because
that's
your
new
recursive,
essentially
that
initial
recursive
still
has
per
client
caching,
but
you're
right.
It
totally
breaks
shared
caching
for
all
the
clients.
So
that's
another
another
reason
beyond
the
latency
hop
why
you'd
want
to
basically
have
that
that
thing
everywhere.
Q
T
A
U
D
J'tia,
this
is
a
very
interesting
idea
and
I
hope
to
see
a
more
specific
implementable
spec
in
the
next
batch
amigos.
I
found
the
current
version
basically
only
describes
the
current
version
only
describes
the
idea
and
many
implementation
details
are
missing,
so
I
hope,
the
next
patch
America
white
and
we
work
on
earth.
Thank
you.
Well,
Nathan,
good
point.
If
that
the
wrong
of
you
depends
on
opt
error,
e
DNS,
I
think
you
basically
cannot
expect
the
recursive
server
to
who
are
it
because
it
is
essentially
a
papaya
protocol.
So
I
guess
this.
Q
D
U
U
No,
the
the
the
ODS
sees
the
complete
set
of
queries
yeah.
So
are
there
any
measures
against
well
using
it
and
if
I
follow
with
second
question
yeah,
do
you
have
any
idea
for
fallback
if
the
queue
name
is
too
long
encrypted,
because
I
can
imagine
Rock
server
sending
a
very
long
cname?
Yes
to
see
that
just
to
force
the
client
to
fall
back
to
normal.
Q
Q
In
the
case
of
fall
back,
I
mean
that's
part
of
the
reason
why
we're
here
talking
to
this
group
is
I
mean
we
certainly
have
our
own
implementation
idea,
which
is
basically
just
to
fall
back
to
regular
DNS.
But
that's
arguably
maybe
not.
You
know
that
you
got
to
do
that
with
care
right,
because
if
somebody
expects
that
they're
gonna
have
a
certain
level
of
privacy
and
we
just
silently
turn
it
into
a
regular
DNS
query
than
it's
probably
not
so
good.
Q
O
Q
Session
keys
can
be
I
mean,
so
the
the
session
keys
can
be
per
hour
doing
a
per
query.
So
yeah.
If
you
had
a
if
routing
changed
your
any
casts
destination
in
the
middle
of
a
query
in
response,
then
that
would
be
a
problem
just
like
any
other.
You
know,
anycast
DNS
response,
but
obviously
whatever's
coming
back
would
either
not
come
back
or
we
need
to
rekey
yeah.
O
D
Q
Q
The
good
point
we
don't
say
anything
about
that,
so
we
might
want
to
think
okay,
we
want
to
consider
make
a
draft
yeah.
That's
also
I,
think
open
for
consideration
and
discussion,
because
you
know,
obviously
we
don't
know
what
what
the
best
thing
to
do
is
there.
So
that's
something
where
the
group
can
help
us.
Okay,
thanks
thanks.
A
Thank
you.
So
so
we
were
gonna,
do
a
stage
two
discussion,
but
that
seems
to
have
gone
off
the
rails,
so
I
think
Brian
and
I
were
just
talking
it.
It
seems
like
we
may
have
to
hope.
I
end
up
doing
like
an
interim
meaning
where
we
just
basically
break
down
the
topics
that
we
have,
because
we
had
two
sets
of
what
Paul
was
gonna
talk
about
the
user
user
world.
A
A
Give
us
a
good
hour
to
sort
of
hash
some
stuff
out.
Anybody
feel
that
their
sorely
opposed
to
that
and
I
think
we'd
rather
do
that
than
wait.
Til
til
Bangkok.
So
anybody
wants
to
speak
up
and
sort
of
bash
on
that.
Just
let
us
know,
but
let's
see
I
would
say
probably
mid
August
unless
we
think
all
of
your
obsession
will
be
on
a
holiday
then,
but
we
should
shoot
for
something
like
an
interim
like
mid
to
end
of
August.
Basically,.
F
J
Lot
of
interest
in
it
can
we
you
know
we
we
want
to
move
this
forward.
The
only
reason
I'm
asking
is
because
you
would
you
know
you
guys
had
limited
what
you
wanted.
The
talks
about
you
know
no
solutionizing
stuff.
Can
you
give
us
some
guidelines
for
how
we
can
do
it
on
the
list
before
the
interim?
How.
C
Yeah
the
question
I
have
is,
as
Tim
mentioned,
we've
got.
We
had
Paul
that
was
going
to
talk
from
from
a
user
perspective.
We
had
Dino
who's
going
to
talk
to
him
implementers
perspective.
I
think
we
want
to
try
and
get
someone
who
runs,
authoritative,
servers
to
also
think
about
what
the
kind
of
requirements
would
look
like
and
I.
Think
in
all
fairness,
we
need
somebody
who
is
a
root
server
operator
as
well.
C
S
Ben
evander
well,
both
Lee
also
includes
some
of
operator
perspectives
in
my
slide.
So
oh
praise.
Please
have
a
look
at
it.
It's
for
the
route
and
for
the
teal,
these
alternative
deployment
models
to
call
for
increased
costs
of
TLS
connections.
Okay,
please
have
a
look
at
the
slides,
might
be
also
help
for
the
discussions
on
the
mailing
list.
A
A
C
So
Tim
and
I
will
will
send
something
out
to
the
list
before
the
end
of
the
week,
so
you
can
chew
on
it,
on
whatever
airplane
flight
you're
gonna
be
on
and
and
we'll
get
the
discussion
going
on
the
mailing
list
and
we'll
let
that
kind
of
guide
how
we
want
to
schedule
any
kind
of
interim
meeting.
So
with
that,
does
anybody
have
any
final
comments?
Questions.