►
From YouTube: DPRIVE WG Interim Meeting, 2021-01-27
Description
DPRIVE WG Interim Meeting, 2021-01-27
B
B
I
would
have
been
fine
with
this
being
slide
free,
but
I
will
fairly
quickly
go
over
what's
in
the
draft,
although
hopefully
most
people
have
read
it
and
then
the
last
slide
is
about
you
know
like
future
directions
and
such
like
that
before
we
start,
let
me
be
super
super
clear.
This
is
one
proposal
on
how
to
do
opportunistic.
B
A
A
B
B
So
the
document
itself
sort
of
has
three
major
parts.
The
use
case,
which
I
think
is
really
the
most
important
part
the
protocol
part-
is
actually
very
minimal
and
actually,
depending
on
how
the
working
group
goes,
could
be
made
even
smaller,
really
the
hard
part
for
people
to
wrap
their
head
around
is
the
use
case.
B
So
hope
I
have
a
you
know
slide
on
that,
and
hopefully
people
can
see
that,
in
fact,
if
the
use
case
needs
to
be
tweaked
a
bit,
that's
fine,
but
the
the
the
use
case
that
we
are
talking
about
here
is
opportunistic.
Only
it's
not
a
blending
of
the
two
or
anything
like
that,
and
then
I
have
a
slide
about
how
the
resolvers
can
enable
this
and
how
the
authoritative
servers
can
enable
this
and
then,
like.
B
B
Slide
so
these
are
pretty
much
the
exact
words
in
the
draft.
The
use
case
is
not.
I'm
sorry
did
someone
hop
in
the
use
case.
Let
me
do
the
negative.
The
use
case
is
not
we
need
this,
and
so
like,
for
example,
yesterday
on
the
list
shock,
the
tour
you
know
express
some
concern
that
people
you
know
would
be
expected
to
implement
this.
That
is
not
in
this
use
case.
B
This
use
case
is
hey
a
bunch
of
reserve
recursive
resolver
operators
who
know
that
they're
going
to
have
to
suck
up
a
little
bit
of
overhead
would
like
to
see
encryption.
You
know
like
encryption's
a
good
thing.
It's
also
that
authoritative
servers
who
are
willing
to
suck
up
some
overhead
want
to
also
want
to
see
that
greater
encryption
there
is
not
the
you
know.
This
use
case
is
nothing
like
the
use
case
for
encryption
on
the
web.
B
This
is
the
dns
we're
not
doing
things
like
opening
up
systems
where
we're
going
to
be
typing
in
our
passwords.
We
are
not
doing
a
lot
of
the
things
for
which
privacy,
which
then
has
to
come
with
authentication
is
needed.
This
is
like,
let's
encrypt
what
we
can
prevent
man
in
the
middles
from
from
from
watching,
unless
they
are
active,
I'm
sorry
prevent
passive
people
from
watching
it.
Would
you
know
that
the
only
people
who
would
be
able
to
break
the
encryption
are
ones
who
are
active
anyways?
B
Let's
just
increase
the
amount
of
encryption
for
the
you
know
for
recursive
to
authoritative,
and
so
then
the
third
bullet
really
nails
down.
How
what
you
know
what
the
part
of
this
is
that
is
opportunistic
is
that
if
tls
cannot
be
set
up
because
of
lack
generally
because
of
lack
of
authentication,
don't
fail
to
serve
the
queries.
Don't
take
that
as
a
reason
to
okay,
I'm
not
going
to
do
this.
C
B
B
Encryption
is
not
free,
so
there
are
additional
costs,
and
these
are
things
that
have
been
well
understood
in
the
web
world
when
they
went
from
it
was
only
your
bank
site
that
used
tls,
or
at
that
point
it
was
just
ssl
to
basically
like
70
80
percent
of
the
websites.
Now,
in
fact,
even
if
you
come
to
them
unencrypted,
they
upgrade
you
to
encryption.
B
You're
gonna
get
for
us
for
the
recursive
to
authoritative
scenario,
you're
going
to
get
extra
round
trips
to
establish
tcp
for
every
every
session.
Right
now,
for
example,
looking
at
the
data
from
the
root
servers
and
again
I'm
not
proposing
this
is
for
the
root
servers.
Only
about
five
percent
of
the
queries
are
go
over
tls
I've
been
told
by
somebody
at
one
of
the
author.
B
You
know
who
runs
one
of
the
authoritative
servers
for
one
of
the
big
tlds
that
that's
about
true,
also
for
them,
so
we're
going
from
five
percent
tcp
to
some
larger
amount.
If
this
gets
really
popular,
it'll
be
a
much
larger
amount.
If
this
doesn't
get
so
popular
still
is
a
larger
amount,
but
five
percent
is
close
enough
to
zero.
B
Where
people
will
start
seeing
things
breathe
heavily
if
they
have
not
tuned
their
kernels
correctly,
just
for
t,
you
know
for
establishing
tcp,
there's
also
a
cost
for
the
extra
round
trips
for
this
tls
establishment-
and
you
know
we
can.
We
can
maybe
limit
that
by
saying
it
should
always
be
tls
1.3.
B
B
It
might
go
really
fast,
it
might
not,
but
it's
certainly
going
to
be
greater
than
zero,
which
is
what
we
have
now.
There
is
cpu
usage
for
tls
establishment,
there's
almost
no
extra
tls,
cpu
usage
for
after
the
tls
session
is
up
for
doing
the
actual
encryption,
but
there
is
a
significant
amount
of
cpu
used
for
tls
establishment.
B
For
us,
though,
still
the
first
two
bullets,
the
extra
round
trips
will
still
always
be
significant,
and
then
there
is
definitely
going
to
be
greater
memory
use
for
holding
the
tls
state.
There
is
also
I'm
sorry.
I
didn't
include
this
as
another
bullet,
but
there's
certainly
greater
memory
usage
for
holding
the
tcp
state
as
well.
B
Those
two
together
are
not
zero
and
so
a
system
that
only
is
having
where
the
memory
overhead
is
only
about
five
percent
of
the
of
the
queries
requiring
tls
there's
going
to
be
greater
memory
usage
again.
Fortunately,
what
we've
learned
from
the
web
world
is
that
even
on
very
active
web
servers
that
amount
of
memory
isn't
big
next
slide.
B
So
you
fill
the
cache
out
of
band
and
you
when,
when
you're
about
to
start
a
connection
to
an
authoritative
server,
you
look
like.
Oh
this
one
does
the
thing
I
want
to
do
great,
or
I
don't
know
so,
I'm
not
going
to
try
it.
Maybe
I'll
put
that
as
a
query
for
later
or
your
cache
might
say.
I
already
tried
that
and
no
they
don't
don't
even
think
of
it.
B
So
you
do
a
tcp
connection.
You
start
tls
and
you
authenticate
only
if
it's
useful
at
this
point
we
don't
have
any
active
drafts.
That
say
why
authentication
is
useful.
Peter
van
dyke
and
a
few
other
people
had
some
in
a
draft.
That's
now
expired,
it's
not
cl.
You
know
there
was
an
interest
in
that,
so
this
bullet
might
get
changed
by
the
working
later.
If
we
decide
that
there
is
no
useful
reason
for
authenticating.
B
If
there
are
useful
reasons,
then
you
do
authenticate
if
you
can
but
seriously
for
people
if
there
isn't
a
useful
authentication
use
case,
you
just
ignore
the
authentication
result.
It
might
be
faster
if
you
didn't
authenticate,
but
there's
a
lot
of
ssl
stacks
that
won't.
Let
you
not
authenticate
you
sort
of
have
to
go
through
the
authentication
and
ignore
it
again.
That's
a
cpu
usage,
not
a
huge
one.
So
that's
all
that
is
the
entire.
B
How
resolvers
would
turn
this
on
notice
that
there's
almost
no
interoperability
here?
The
only
thing
where
there's
interoperability
is:
what
port
do
I
start
on
if
I'm
going
to
do
tls
or
what
other
port
do
I
start
on,
if
I'm
going
to
do
doq
other
than
that,
how
you
run
your
cache,
how
you
authenticate
or
not,
or
whatever
none
of
that
has
interoperability
issues,
and
I
got
a
little
bit
of
criticism
that
the
current
giraffe
has
too
much
prescription.
B
B
D
B
B
Then
you
don't
really
even
need
a
good
certificate
per
se.
You
could
just
use
a
self-issued
certificate
that
no
one
would
be
able
to
authenticate.
You
know
cool
that.
You
know
the
the
certificate
stuff
is
covered
in
the
draft,
but
that's
very
much
open,
and
it
very
much
depends
on
how
the
working
group
wants
to
consider
this
in
light
of
other
proposals,
and
then
you
just
serve
normally
that's
it.
It's
just
turn
on
tls
watch
stuff
happen
next
slide.
B
So
this
is
my
last
slide
here.
So
we
starting
in
you,
know
we're
only
18
minutes
in
then
we'll
be
slide
free.
So
one
of
the
questions
is:
does
the
work
group
want
to
adopt
it?
That's
you
know,
certainly
always
the
other
one.
The
current
document
after
we
have
this
similar
discussion
to
this
during
the
meeting
last
fall.
The
the
working
group
meeting
last
call
people
said
that
I
should
focus
on
just
doing
probing
for
how
to
how
to
add
discovery
for
the
cash.
B
B
The
working
group
has
to
pick
something
to
do
with
the
optional
authentication
and-
and
I
give
pretty
much
the
two
choices
here
and
they
are
extreme
choices,
but
I
think
there
really
isn't
anything
in
the
middle
I
mean
if
I'm
wrong,
that's
fine,
but
either
the
working
group
would
say
we
define
where
authentication
during
our
opportunistic
is
useful,
and
if
so,
then
I
need
to
write
more
about
handling
authentication
or,
if
work
group
decides
that
there
isn't
any
reason
to
authenticate
during
opportunistic
again.
This
is
regardless
of
the
other
one.
B
E
I
think
that
probably
the
authentication
could
be
removed
as
you
offered,
among
other
things,
the
current
text
doesn't
doesn't
make
it
clear
to
me
what
identity
one
would
authenticate
and
there
are
several
different
potential
reference
identities
in
play
here.
If
we
can't
pick
one,
then
we
risk
an
interoperability
problem.
If
people
disagree
about
what
the
appropriate
identity
is.
E
B
Sure-
and
I
I,
as
I
said
in
the
current
draft,
the
data
that
I
use
the
research
that
I
used,
I
haven't
published,
yet
it's
in
the
long,
tedious
publication
process
within
icann.
I
am
assuming
that
I'll
have
that
published
within
a
month
and
a
half,
but
where
I
got
those
numbers
and
to
be
clear,
those
numbers
are
based
on
a
99th
percentile
from
a
distant
place.
E
B
E
A
B
E
But
if
you
imagine
a
future
resolver
that
implements
both
your
opportunistic
pattern
described
here
and
an
authenticated
pattern,
then
if
you
hit
an
authentication
failure
on
a
properly
authenticated
query,
you
should
fail
hard
and
not
correct,
and
that
should
override
this,
so
it
just
the
text
should
make
clear
that
that
the
fallback
can
be
overwritten
by
authentication.
I
think
I
can
put
that
in
the
security.
B
Considerations
section
sure,
if
you
know,
which
is
where
we
often
say
if
something
different
happens
in
the
future,
because
we
still
have
questions
of
how
that
would
go
and
who
would
use
it
and
such
like
that.
But
yes
putting
something
in
there
saying
don't
you
know
like
like
there
might
be
some
reason
why
you
don't
want
to
fall
back
in
the
future
that
has
been
described
in
other
places.
Sure
yeah.
C
B
Why,
oh
because,
for
two
reasons
one
is
that
requires
every
offen,
every
authoritative
server,
to
be
able
to
put
a
tlsa
record
for
the
name
of
the
server
and
they
may
not
be
in
control
of
that.
That's
one
reason,
but
the
other
is
that
it
requires
tlsa
requires
you
to
be
a
validating
resolver,
and
we
know
that
fewer
than
30
percent
of
the
resolvers
on
the
internet
are
validating.
I
wouldn't
want
to
restrict
this
to
them.
C
Okay,
well,
I
guess
that's
something
to
be
discussed
more
than
I'm,
not
I'm
not!
I'm
not
sure.
I
buy
your
first
argument
that
that
people
aren't
always
in
control
of
their
of
their
names,
but
I
guess
we
can.
We
can
fight
about
that
later,
yeah
and-
and
one
last
point-
it's
probably
implied
in
in
the
draft,
but
maybe
it
could
be
made
more
more
explicit
that
you
know
any
authoritative
server
that
doesn't
support
encryption
shouldn't
have
to
you
know,
do
anything.
A
F
All
right
a
few
points
I
support
adoption.
I
really
like
how
this
draft
has
found
a
middle
ground
where
probing
is
not
in
the
host
resolver
path.
This
also
means
that
for
any
fresh
start,
resolver
the
first
few
curious
queries
to
some
name.
Server
will
be
unencrypted,
but
that's
a
trade
over
making.
Here,
let's
see
what
else
did
I
have
to
bench
last
point?
It
would
be
nice
if
name
servers
that
do
not
support
any
encryption.
Do
fail
fast
on
port
853,
but
I
also
see
how
we
cannot
demand
that
of
them.
F
So
if
you
want
to
do
authenticated-
which
we
are
not
mostly
not
talking
about
here-
but
if
you
want
to
do
authenticated,
then
you
need
to
fix
that
on
the
tld
side.
And
if
you
are
using
tls8
just
as
a
signal,
then
you
will
still
need
to
look
up
the
name
servers
for
a
domain
at
the
authority,
authoritives
unencrypted,
so
you
will
still
be
leaking
the
domain
name
and
as
for
ben's
point
about
people
not
being
in
control
or
then
saying,
I
believe
people
are
generally
generally
in
control
of
the
name
server
names.
F
B
B
853
is
cute,
but
in
in
the
transport
world
there
is
a
are
very
strongly
opinionated
people
on
both
sides
of
the
argument
of
whether
overloading
a
port
number
and
this
an
already
assigned
port
number
is
a
good
idea
because
we
save
port
numbers,
even
though
we
don't
need
to
save
them
or
it's
a
bad
idea,
because
it
overloads
things
and
it
causes
confusion.
So
I'm
not
I.
I
will
probably,
if
I
say
853,
currently,
I'm
going
to
take
it
out
and
we
may
end
up
with
it.
Anyways.
F
B
And
hopefully
again,
my
personal
preference
is
that
we
we
also
get
doq,
that
this
doesn't
have
to
be,
that
the
the
dns
over
quick
will
be
a
better
solution
for
this
it'll
take
a
long
time,
blah
blah.
But
you
know
five
years
from
now.
If
assuming
this
goes
forward,
I
would
be
thrilled
if
most
of
this
traffic
was
actually
running
over
quick
sure.
F
E
On
the
topic
of
tlsa,
I
tend
to
think
that
somehow
tlsa
will
end
up
playing
a
role
in
our
authenticated,
authoritative,
encryption
story,
but
exactly
how
that
works
is
yet
to
be
determined.
I
think
that
we
don't
need
to
worry
about
it
right
now
at
some
point
in
the
future,
when
we've
figured
that
out,
we
can.
We
can
circle
back
and
see
if
it
has
some
effect
on
this.
I
kind
of
think
it.
A
A
All
right
thanks
ben
thanks
paul,
and
so
what
we're
going
to
do
now.
Well,
first
of
all,
I'm
going
to
remind
everybody
that
they
should
go
into
the
the
cody
md
blue
sheet
and
and
sign
the
our
our
our
our
our
attendee
list
is,
it
evidently
is
is
far
larger
than
the
number
of
people
who
have
signed
the
blue
sheets.
So
what
we
want
to
do
now
is
take
about
40
minutes
or
so
to
discuss
some
of
the
the
the
aspects
of
of
the
optimistic
encryption
draft
and
talk
about
it.
A
So
before
we
so
okay
thought
somebody
jumped
in
the
queue
and
then
they
jumped
out.
So
what
I
want
to
do
is
just
have
this
as
an
open
discussion,
so
you'll
use
the
same.
You
know,
plus
q,
minus
q,
notation
in
the
in
the
webex
chat
and
we'll
try
and
do
this
as
orderly
as
possible,
but
I
think
the
first
topic
that
that
I'm
interested
in-
and
I've
heard
several
people
mention
at
least
to
me
at
a
in
a
variety
of
situations-
is-
is
really
kind
of
related
to
authentication
that
paul
brought
up.
A
You
know
we,
our
our
charter,
is
focused
on
the
privacy
aspects
of
moving
data
from
a
from
a
recursive
resolver
to
an
authoritative.
So
so,
if
people
have
comments
or
thoughts
on
the
the
impact
of
this
approach
to
the
recursive
resolvers
and
just
as
kind
of
a
primer,
I'd
like
to
focus
more
on
the
on
the
authentication
question
first
but
but
any
topic
related
recursive
resolver
is
is,
is
fair.
A
A
So
so
either
people
can't
hear
what
I'm
saying
they're,
either
off
signing
the
blue
sheets
or
they're,
not
sure
what
what
what
what
we?
What
would
be
the
topic
related
to
authentication.
So
I
will
hear
from
you
we
can
hear
you
yeah
yeah,
I
yeah,
so
so
my
my
basic
view
of
this
is
that
you
know
our
focus
is
more
on
protecting
the
data,
that's
in
transit
and
not
necessarily
trying
to
authenticate
the
the
entity
that
is
providing
the
answer.
E
E
Okay,
I'm
not
sure
what
perspective
I
I
can
claim
to
represent
here,
but
I
think
opportunistic
encryption
is
valuable
and
I
I
I
so
I'm
a
huge
advocate
of
authenticated
encryption.
That's
downgrade
resistant,
but
I
think
opportunistic
is
very
valuable
here,
especially
for
shaking
out
those
resource
utilization
concerns
that
paul
highlighted.
G
B
A
Yeah,
I
I
agree
with
that
perspective,
paul
and,
and
just
to
be
clear.
You
know
this
is
this
is
just
a
a
working
discussion
and
you
know
we.
We
have
to
make
sure
that
we
we
we
get
the
feedback
from
other
participants
in
the
working
group
who
have
had.
You
know.
Contrary
views
to
this,
so
you
know,
don't
think
that
anything
that
we
we
we
decide
or
think
today
is
going
to
be
set
in
stone.
The
working
group
on
the
mailing
list
still
has
to
to
do
the
consensus
on
what
they
look
like
peter.
F
Hello,
I'm
not
speaking
for
any
resolve
for
operators,
but
I
am
aware
of
cloudflare
and
facebook
having
an
agreement
where
cloudflare
can
send
them.
Edn's
client
subnet
data,
which
they
do
not
send
to
anybody
else
because
they
have
agreed
on
using
tls.
However,
they
are
doing
this
by
agreement,
so
they
don't
need
anything
we
do
for
that.
A
G
Yeah
I
mean,
if
we
are,
I
mean
I
don't
like
probing,
but
if
we
are
doing
opportunistic,
that
is
the
only
way
to
do
that.
The
other
thing
is
what
peter
said:
if
you
have
an
agreement-
and
you
know
that
the
server
you're
going
to
support
it,
then
you
can
kind
of
hardwire
it,
but
for
as
a
dns
person,
I'd
rather
see
something
where
we
have
in
the
resolution
process
an
authenticated
way
of
getting
to
a
server,
but
that's
obviously
further.
G
A
A
A
F
Peter
I
just
breaking
the
signs
here
a
bit.
I
believe
the
draft
indeed
covers
most
of
the
things
needed
from
an
authoritative,
and
I
I
think
I'd
like
to
echo
what
maybe
ben
said
or
maybe
not,
that
we
probably
shouldn't
specify
authentication
at
all,
so
the
document
could
be
shorter
and
then
the
only
open
question
is.
If
we
want
to
also
do
authenticated
in
the
future,
then
it
would
be
great
if
people
don't
have
to
rebuild
everything,
but
it
might
be
unavoidable.
F
A
A
H
H
You
know,
for
us,
availability
is
priority
number
one,
and
if
the
you
know
the
com
servers
or
the
root
servers
we
operate,
take
any
kind
of
of
a
downtime
hit.
That
would
be
very
bad.
You
know
from
an
internet
infrastructure
perspective,
so
we're
going
to
be
watching
primarily
to
see
how
this
all
plays
out.
You
know
before
we
make
any
decisions
about
turning
anything
on.
B
B
B
B
B
So
I
think
that,
even
though
this
is
completely
non-normative,
I
think
that
a
discussion
of
this
would
would
be
reasonable
in
the
draft
as
a
way
of
saying
if
you're,
an
authoritative
server-
and
you
want
to
start
looking
at
this
here-
is
how
you
could
do
a
soft
roll
for,
adding
and
and
then
see.
You
know
see
what
the
implications
are.
B
I
agree
with
what
scott
hollenbeck
just
said
in
the
sense
that,
as
I
said,
my
vanity
domain
name
is
proper.com,
so
I
don't
want
to
see
the
dot-com
name
servers
meltdown,
but
they
could
also,
possibly
if
they
felt
like
it.
I
don't
work
for
verisign,
not
telling
them
what
to
do.
They
could
turn
it
on
on
one
of
the
zillion.com
name.
Servers
see
what
happens
so
anyways.
I
think
that
if
we
adopt
this
document,
I
think
a
an
operational
discussion
of
it.
I
I
Are
we
really
saying
that
the
the
perform
the
privacy
guarantee
that
might
be
offered
is
very
minimal
from
the
point
of
view
of
the
authoritatives?
That's
question
number
one.
In
other
words,
they
hope
you'll
get
what
you
want,
but
you
might
actually
never
get
what
you
want.
You
may
have
a
you
know.
You
may
have
quite
a
difficult
time
with
that
question
two
is:
could
you
sorry?
I
want
to
put
three
questions
in
because
I
don't
talk
too
much.
The
question
two
is
for
the
sake
of
doing
the
soft
roll
out.
I
I
believe
you
could
even
use
a
name
server
which
is
not
in
the
name
server
set
and
and
have
people
test
against
it
with
explicit
reference
to
it.
It
wouldn't
give
you
a
lot
of
sense,
and
so
you
could
load
against
it
and
see
its
performance
behavior
without
without
actually
having
customers
getting
it
and
having
disappointments.
I
And
the
third
question
is:
would
it
be
in
the
scope
of
this
document
for
to
advise
very
privacy,
oriented
recursive
servers
to
identify
the
the
the
the
parts
of
the
footprint
that
do
tls
and
try
to
maintain
them
in
some
form
so
that
they,
they
really
don't,
usually
send
you
off
to
a
non-tls
one?
If
you
are,
if
you're,
if
you
you're
a
client
of
them-
and
you
know
they
know
you
care
about
privacy,
so
three.
D
Yeah
paul
when
paul
spoke
about
cashing,
that's
a
triggered.
Another
evil
thought
that
I
had.
I
think
it's
quite
common
to
come
across
authoritative,
name,
servers
that
have
been
short
lived
time
to
look
values
on
the
address
records
for
the
ns
record.
So
then
this
deck
has
got
time
to
the
value
of
perhaps
a
few
hours
in
a
day
or
so.
D
So
you
could
run
a
server
for
one
query,
which
is
supporting
tls
the
provider
flips
to
another
server
on
the
same
physical
ip
address,
and
then
that
other
server
doesn't
do
tls
at
all
and
that
messes
up
the
cash
that
paul
was
talking
about
for
keeping
track
of
this
stuff.
Is
that
a
corner
case?
We
should
worry
about.
J
B
B
It
is
easy
to
show
that
that
privacy
guarantees
are
going
to
go
to
hell
on
this
one.
For
example,
if
you
start
up
tls
and
the
the
the
resolver,
the
resolver's
client
and
the
authoritative
server,
don't
agree
on
encryption
algorithms,
then
tls
won't
get
set
up
and
that's
it
says
that
explicitly
in
the
draft.
So
there
is
no
privacy
guarantee
here.
B
Opportunistic
really
means
just
if
we
can-
and
I
guess
that
actually
ties
to
allison's
third
question
about
the
privacy
oriented
resolvers
with
you
know:
we've
written
about
she's
written
about,
certainly
in
the
working
group.
This
is
unrelated
to
them
other
than
this
gives
them
a
in
my
mind,
non-documentable
way
of
doing
better,
but
you
know
any
documentation
that
comes
out
of
this.
I
think
I
I
don't
think
I
don't
think
it
should
be
documented.
B
I
don't
I
don't
I
mean,
maybe
a
privacy
oriented
resolver
might
say
in
addition
to
what
I
promised
you
before.
I
was
also
able
to
encrypt
20
of
my
traffic
to
authoritative
servers,
but
who
knows
all
of
that
might
have
been
you
know,
hit
by
a
man
in
the
middle.
I
don't
know
so
I
would
say,
let's
stay
out
of
that.
Maybe
I
I
need
to
say
that
in
the
document
is
that
the
guarantees
are
weak
and
not
even
verifiable.
So
let's
not
go
there.
B
I
don't
want
this
document
to
be
saying
that
maybe
if
we
adopt
the
document
and
we
get
a
year
or
two's
experience,
then
we
can
come
back
and
document
some
of
the
experience,
but
I
really
want
this
to
be
hard
work
for
the
resolver
vendors,
sorry
folks,
but
I
do
think
that
you're
going
to
have
to
be
creative.
I
think
you're
going
to
have
to
talk
to
each
other.
I
think
you're
going
to
have
to
compete,
which
I
think
is
very
cool
for
having
the
better
cash
the
more
effective
cash,
the
bigger
cash
whatever.
B
A
E
Hi
same
topic,
so
you
spoke
earlier
paul
about
the
idea
of
turning
this
on,
for
just
one
of
the
many
name
servers
for
a
zone
correct
depending
on
so
there
are
a
few
ways
to
think
about
that.
One
way
is
to
say
we
turn
this
on.
Just
for
one
named
name
server,
you
know,
essentially,
for
one
ns
record.
The
other
way
is
to
say
that
we
turn
it
on
for
one
ip
address,
one
one
literal
server,
that's
among
the
ip
addresses
the
multiple
ip
addresses
that
represent
one.
E
E
B
Fair
point
I
can,
I
can
see
that
as
in
it,
if
it's
done
operationally
poorly
you're
going
to
possibly
be
blocking
people
in
ways
you
don't
know
and
because
you
don't
you
don't
control
the
way
that
the
resolvers
are
going
to
be
running
their.
You
know,
there's
going
to
be
many
kinds
of
caches
on
the
resolvers
and
they're
right.
Here
are
some
things
to
think
about.
Okay,.
E
Suddenly
you
have
a
marked
increase
in
latency
for
all
of
your
users,
because
there
are
a
ton
of
users
who
are
trying
to
hit
other
server
nodes
and
waiting
for
a
timeout
on
tls
before
falling
back,
because
they
got
the
they
got
this
entry
in
their
transport
cache.
Now
maybe
you
know
on
failure.
We
immediately
wipe
the
you
say
like
on
failure.
You
need
to
wipe
the
transport
cache.
B
E
Yeah-
and
I'm
very
I'm
definitely
on
on
the
same
page
as
alex
here,
that
we
need
good
support
for
gradual
rollout
across
any
cast
systems,
and
so
that
that
basically
is
talking
about
transport
cache
behavior,
and
we
can
imagine
crazy
things
like
an
explicit
opt
out.
You
can
place
a
particular
record
in
your
zone.
That
says
like
no,
don't
do
opportunistic
with
this
zone
and
that
allows
you
to
do
a
gradual
rollout
and
not
get
user
traffic
until
you're
ready
for
it.
But
even
even
without
that
complexity,
you
know.
E
B
K
Apparently
one
of
the
things
a
lot
of
operators
found
useful
was
the
ability
to
gather
reports
as
to
how
other
people
are
perceiving
what
you've
configured
on
your
servers,
and
so
another
thing
they
liked
was
to
be
able
to
indicate
that
they're
only
testing
they're
not
being
really
serious.
That
was
maybe
more
in
the
context
of
dmarc.
K
If
they
choose
to
do
it,
you
know
I
I
see
yours
config
at
this
time
with
this
particular
instance
as
authenticating
or
not
authenticating,
or
using
this
or
that
of
the
other
set
of
parameters.
So
I'm
not
arguing
strongly
for
that.
Just
operations.
People
said
in
the
context
of
mail
that
was
really
useful,
especially
while
in
this
partial,
opportunistic
deployment
stage,
so
I
think
it
might
be
worth
considering
here
is
that
the
case.
F
Yes
hi.
I
initially
agreed
with
jason
that
the
draft
was
too
prescriptive
and
I
still
agree.
I
also
agreed
with
jason
that
it
should
be
shorter,
but
after
hearing
paul
and
ben
just
discuss
this,
I
also
feel
that
the
draft
should
describe
the
concerns
without
telling
you
what
to
do
about
it,
and
I
would
be
happy
to
help
with
that.
D
But
perhaps
we
have
to
think
about
the
scenario
where
a
resolving
server
fails
to
be
able
to
locate
a
certain
authority
server,
that's
offering
tls
and
then
goes
bersep
by
chasing
around
all
of
the
ns
records
in
the
are
offset
trying
to
speak
tls
to
them
and
not
succeeding
and
just
getting
itself
either
in
an
infinite
loop
or
worst
case
flagging.
All
the
authoritative
servers
with
excessive
queries
and
tcp
connections.
A
A
A
A
A
You
know
gladly
have
people
correct
me,
since
I'm
I'm
trying
to
multitask
with
with
you
know,
tracking
the
the
queue
and
and
and
take
notes
at
the
same
time,
so
it
it.
It
seems
clear
that
people
are
interested
in
having
the
work
group
do
a
poll
for
adoption
on
on
the
opportunity,
encryption,
drought.
A
There
are
some
comments
that
were
made
that
I
think
paul
said,
would
would
probably
be
reflected
back
into
the
document
does.
Does
anybody
have
any
concerns
with
doing
an
adoption
call
prior
to
those
updates
being
made
and
and
the
reason
why
I
asked
that
question
is
because
once
the
document's
adopted
by
the,
if
the
document
is
adopted
by
the
working
group,
then
the
contents
will
be
consensus
driven
and
we
can
have
you
know
all
sorts
of
discussions
about.
You
know
what
should
or
shouldn't
be
in
the
document.
A
A
A
A
A
A
B
I
think
that
having
a
document
author
participating
in
an
interop
event
is
a
bad
idea,
but
having
having
the
document
authors
only
hear
about
a
summary
result
is
also
a
bad
idea.
So
michael
richardson,
who
I
can
see
on
the
call,
probably
remembers
that
we
had
that
very
issue
on
a
lot
of
the
ipsec
interoperability
events,
but
I
I
would
be
if
you
know
if
the
document
is
adopted
and
anyone
pulls
together
an
interop
event
and
I'm
happy
to
organize
one
as
long
as
I'm
not
a
participant,
I
I
would.
I
I
really
like
the
idea
of
an
interop
and
I'm
sure
that
we
over
in
the
dns
privacy
project
will
support
that
and
participate
in
that.
Rather,
I
also
wanted
to
mention
that.
I
hope
that
it's
all
right
to
plug
this,
but
on
the
21st
of
january
we
have
the
dns
privacy
workshop
again
at
ndss
and
one
of
our
panels
we're
not
having
a
panel
but
we're
going
to
have
an
open
discussion
about
so
the
research
directions
related
to
everything,
and
I
think
there
will
be
a
lot
of
interest
in
research.