►
From YouTube: IETF107-ADD-20200324-1946
Description
ADD meeting session at IETF 107
2020/03/24- 1946
https://datatracker.ietf.org/meeting/107/proceedings
A
79
so
seems
a
pretty
good
crowd
seems
like
it's
time
to
get
going.
I
just
posted
into
the
jabber.
The
link
directly
I
see
some
people
having
trouble
with
some
of
the
media
materials.
Getting
them
downloaded
successfully.
I,
don't
know
what
the
problem
is.
I
do
know
the
individual
slide
material
is
directly
available
under
the
ad
D
group
web
page
in
data
tracker
under
meetings
and
then
aneema
t
riyals
for
this
ITF
107.
You
can
directly
download
them
there
or
you
can
just
watch
your
screens
and
play
along
at
home.
A
A
Message
for
somebody
please
put
a
plus
Q
into
the
WebEx
chat
session.
If
you
want
to
get
out
of
the
queue
for
speaking
when
we
open
the
lines,
put
a
cube
and
we'll
keep
track
of
that
and
call
you
when
it's
your
turn
as
well.
Please
do
not
use
the
WebEx
chat
session
for
conversations
to
the
whole
group
for
that
either
use
jabber
or
use
direct
messaging
between
people
we're
going
to
try
to
keep
the
main
session
in
WebEx
for
managing
the
queue.
A
A
A
You
I
see
one
person
you
see
one
person
jabber
commented
so
so
okay,
so
we
got
just
some
some
people
in
jabber
we
got
some
people
eat
your
pad.
I
think
we
are
set
to
go
for
those
who
haven't
read
the
instructions
for
the
normal
participants.
The
way
we're
doing
blue
sheets
is
for
people
to
go
into
the
ether
pad
and
at
the
bottom
of
the
inner
pad.
You'll
find
a
list
of
names
and
affiliations,
go
ahead
and
add
yours
to
that
list.
Please,
okay,.
A
A
And
welcome
to
f-107
ad
D
virtual
working
group
we're
going
off
for
the
next
two
hours
and
talked
about
the
wonderful
world
of
discovery
and
conveyance
the
information
about
resolvers
to
clients.
This
is
our
agenda.
David,
Lawrence
and
myself
are
your
chairs
will
have
an
agenda
bash
all
bye,
I
believe
Chowdhury
is
gonna,
speak
to
the
drafty
and
yari
put
together
talking
about
resolver
distributed
resolver
selection,
then
Tommy
Pauly
will
speak
on
discovery,
selection
directions.
Dan
wig
will
present
a
two
different
working
drafts.
A
B
A
Let's
move
on
so
I
want
ad
D.
This
has
been
a
long
time
coming.
We've
had
a
couple
boss
that
touched
around
the
topics
of
where
a
DD
event
ended
up.
This
started
out
as
sort
of
a
varied
eccentric
discussion.
It's
evolved
I
think
to
cover
a
sort
of
more
generic
discovery
of
encrypted
DNS
provided
resolvers,
whether
they
be
dot
or
doe.
A
So
we're
not
Doe
centric
we're
equal-opportunity,
the
the
Charter
as
it
got
developed
over
the
last
few
months,
went
through
a
lot
of
changes
and
so
I
invite
everybody
to
become
familiar
with
where
it
ended
up.
It's
a
very
narrowly
scoped
Charter,
we're
specifically
focused
on
the
questions
of
how
do
you
discover,
resolvers
and
also
charter
to
develop
a
mechanism
or
resolvers
to
convey
information
back
to
the
client
such
that
the
client
can
use
that
information
to
make
decisions
on
where
to
which
resolver
to
pick?
A
We
are
not
here
to
talk
about
policy,
we're
not
here
to
talk
about
UI
interfaces
and
the
clients.
All
the
other
kind
of
stuff
is
out
of
scope.
We're
really
limited
to
the
technical,
nuts
and
bolts
of
discovery
and
conveyance
of
the
information.
The
rest
of
us
left
up.
Somebody
else
at
the
moment.
That's
a
Dave.
You
want
to
make
any
comments.
C
Yes
quickly,
you
already
covered
a
little
bit
of
how
we're
managing
the
queue
I
wanted
to
add
the
additional
note
that
will
save
questions
for
the
end
of
presentations
and
not
really
be
able
to
do
an
interrupt
cute
and
when
you
request
in
WebEx
chat
to
be
added
to
the
queue.
If
your
handle
does
not
reflect
your
full
name.
Could
you
please
include
your
name
and
your
cue
list?
Thank
you.
A
E
E
F
E
This
is
the
key
question
we're
trying
to
ask
here
is:
can
you
reduce
the
concentrate
of
information
about
Kline?
Thank
you
by
distributing
across
different
resolvers
and
the
reason
we
were
talking
to
you
about
it.
Even
though
it's
not
strictly
about
conveyance
is
it
goes
to
the
question
of
how
many
of
these
might
you
collect
if
you
are
a
client
that
is
looking
for
DNS
services
or
trying
to
gather
information
about
DNS
services?
E
So
this
is
what
we
believe
is
a
set
of
common
DNS
resolver
selection
patterns.
The
first
one
is
there's
a
single
confers
over
and
all
queries,
click
for
that.
The
second
is,
there
is
a
resolver
used
for
all
the
local
interfaces,
but
a
separate
was
configured
for
PPN
interfaces.
That
last
is
that
there
are
per
interface,
DNS
resolver
lists,
it's
our
intuition,
that
these
are
kind
of
roughly
ranked
in
terms
of
color,
I'm,
gonna,
but
I'm
afraid
we
don't
have
any
data
to
share.
E
And
this
is
sort
of
what
happens
when
you
have
a
set
of
configured
resolver,
what
the
query
patterns
look
like.
So
in
the
first
case,
there's
one
computers
over
so
that
result
would
notice
everything
about
the
clients,
query
traffic,
but
no
one
else
does
and
that's
an
important
thing
that
didn't
quite
fit
on
this
line.
In
the
second
case,
there's
a
result
very
used
for
all
local
network
interfaces,
but
a
separate,
resolver
VPN
interfaces.
E
In
this
case,
the
covers
offer
gets
all
the
query
traffic,
except
for
the
APN
and
the
beeping
kids,
all
the
pass
through
the
tunnel
per
interface
DNS
was
over
listed.
It
does
exactly
what
it
says
in
the
team
and
each
resolver
gets
queries
only
for
the
traffic
on
that
interface
and,
if
you
said,
split,
DNS,
spread
of
two
and
so
phone
for
bread
and
three
collector
cookie
actually
make
that
two
or
three
cookies
in
the
common
case
and
next
levels.
E
So
what
are
the
privacy
implication
of
these
common
approaches?
Well,
that's
fairly
obvious
to
see
if
full
ones
of
these
resolvers
configured
said
all
of
us
specific
clients,
queries
to
all
of
the
result
was
available
to
it
and
all
of
them
would
know
about
all
of
their
resolution.
Events
that
clearly,
is
not
going
to
be
the
best
way
to
reduce
the
information
leaked
out
into
the
world
about
the
client.
E
You
have
had
to
do
this
in
the
second
ascent.
All
queries
to
one
was
over
that
seeing
everything
if
that's
a
resolver
that
you
believe
is
not
going
to
read
that
data
further,
that
can
be
an
appropriate
approach
and
having
a
separate
resolver
for
VP
interface,
avoids
queries
via
that
network
leaking
right.
So
if
you
don't
want
the
information,
what's
the
network
VPN
leaking
out
into
the
world,
that's
that's
a
useful
thing
to
do,
but
you're
probably
still
going
to
get
a
whole
bunch
of
information
going
to
a
single
is
over.
E
G
E
E
E
So,
for
example,
if
you're
concerned
about
queries
being
visible
on
the
wire,
then
select
that
offer
Steve,
Quixote
or
do
edge
is
clearly
an
advantage
and
if
you
have
knowledge
of
their
policy,
selecting
ones
that
match
your
policies
are
also
potentially
useful
if
their
privacy
properties
are
included,
policies
but
whole
bunch
of
trade-offs,
and
we
kind
of
go
into
them
a
bit
in
our
draft,
and
it
turns
out
not
to
be
at
all
simple
to
devise
the
system
that,
in
in
every
case,
is
going
to
improve
the
privacy
of
a
client.
In
fact,
they're.
E
The
trade-offs
may
mean
that
by
protecting
the
privacy
of
a
single
client
you,
you
may
be
reducing
the
total
set
of
clients
using
specific
resolver
and
thus
having
implications
beyond
one
client.
So
before
going
through
those
in
detail
and
in
fact
we're
hopefully
not
going
to
go
through
them
in
detail
today
at
all,
we
wanted
to
post
these
questions
to
the
work
next
slide.
Kids.
E
And
sort
of
the
basic
do
you?
Is
this
the
right
place
to
solve
this
problem
set
of
questions?
Mr.
working
Kirk
willing
to
consider
approaches
that
result
in
multiple
DNS
resolvers
being
discovered,
because
if
the
answer
to
that
is
yes,
then
the
key
tucking,
and
if
the
answer
is
no,
that's
not
really
in
scope
or
wee-wees
work
and
don't
work
on
that,
then
we'll
have
to
find
other
places
to
socialize
this
work.
E
The
second
question:
if
the
answer
to
that
does
Travis
is
the
working
willing
to
consider
optimizations
concentration
is
information
about
climb
activity
and
that
that's
a
different
optimization
than
some
of
the
ones
we've
already
discussed,
and
so
it's
important
to
recognize.
This
is
involve
some
trade-offs
that
the
working
group
to
discuss
to
be
thanked.
A
H
I
was
confused.
Okay,
thank
you.
So
thanks
Ted
for
sharing
this
I
think
it's
a
really
good
overview
of
the
question
space
and
how
this
interacts
with
privacy
considerations
in
a
way
that
it
was
further
than
what
the
Charter
discussion
was.
I
have
to
have
one
point
and
then
kind
of
response
to
your
questions.
First,
just
as
I
can
it
when
you
have
the
ordering
of
the
types
of
resolvers
that
you
find
to
be
most
common,
you
listen.
H
You
know
having
the
one
resolver
that
we
use
for
everything
on
the
device
followed
by
the
split
VPN
case,
followed
by
the
per
network
case,
at
least
in
my
experience.
I
would
actually
expect
that
the
per
network,
local
network
resolver,
is
going
to
be
the
most
common,
at
least
as
the
default
for
most
client
operating
systems.
This
is
definitely
true
for
iOS
and
Mac
I.
Imagine
it's
the
same
for
Microsoft
operating
systems
when
Ron,
both
Wi-Fi
and
a
cell
network.
H
The
queries
on
those
different
interfaces
use
what
is
provisioned
locally
and
that's
really
important
for
a
lot
of
the
local
network
interactions.
So
I
think
we
should
view
that
kind
of
as
the
status
quo
and,
if
that's
not
being
done
when
we
are
selecting
just
one
resolver
for
everything,
regardless
of
the
interface,
that's
breaking
a
lot
of
the
recommendations
about
provisioning
domains.
That
came
out
of
the
multiple
interfaces
group,
then,
to
your
questions
regarding
you
know,
should
we
consider
approaches
that
result
in
multiple
DNS,
resolvers
I?
Think
absolutely?
H
Yes,
we
do
need
to
be
concerned
about
that,
as
a
group
I
think
it's
fundamental
to
the
discussion
in
the
Charter.
If
we're
only
interested
in
getting
one
thing,
we're
missing
a
lot
of
the
new
law,
it's
about
how
to
interact
with
the
network
and
I
to
the
point
of
reducing
the
concentration
of
information.
H
I
do
think
that
is
very
useful,
but
I
would
challenge
us
to
when
we
are
looking
at
that
to
consider
the
privacy
impact
in
the
data
leakage,
not
just
in
the
resolution
flow,
but
in
the
subsequent
connections,
because
that's
kind
of
a
whole
package
about
what
information
is
getting
out.
If
we
don't
consider
how
we
send
our
names
in
TLS,
SNI,
etc,
then
we're
missing
the
whole
picture.
Thank
you
for
this.
F
Hi
so
Ted.
Thank
you
for
the
presentation.
My
question
was
about
the
interface
selection,
so
I
I'm,
assuming
that
what
you
mean
by
interface
is
if,
if
a
device
has
multiple
interfaces
like
Ethernet,
Wi-Fi
and
mobile
broadband,
then
you
perhaps
use
different
DNS
resolvers
for
them.
I
guess
there
needs
to
be
some
some
more
detailed
information
like
is
it?
Is
it
fine
that
you
discovered
the
DNS
resolver
on
that
interface,
but
that
interface
is
no
longer
up,
because
most
stacks
currently
allow
you
to
only
have
one
network
interface
up
at
a
time.
F
I
know
there
is
MP,
TCP
and
and
so
on,
but
even
though
the
left
of
I
am
currently
using
does
support
all
three
I'm
currently
connected
only
with
it
with
mobile
problems,
I
think
some,
perhaps
some
more
explanation
whether
that
interface
needs
to
be
up
or
like
can
I
also
use
the
dns
resolver.
That
was
discovered
when
the
interface
was
up
in
the
past,
but
is
may
no
longer
up
and
running
and
I'm
no
longer
sending
traffic
on
on
that
yeah
I
guess
some
more
explanation
would
be
useful.
E
I
J
E
C
C
C
K
K
Tommy
said
Thank
You
marine
about
the
ordering
of
these
things.
It
does
seem
to
me
that
the
VPN
case
is
basically
subsumed
by
the
multiple
interface
case,
because
what
you're
talking
about
is
the
multiple
interface
case,
but
one
of
the
interfaces
happens
to
be
a
virtual
interface.
It's
acting
almost
entirely
the
same
as
the
common
case
for
multiple
interfaces,
so
I
don't
know
that
you'd
necessarily
need
to
separate
those
two
out.
Maybe
you
want
to
make
a
separate
claim
about
with
multiple
interfaces.
There
are
two
ways
to
deal
with
them.
K
As
far
as
my
question,
if
the
working
group
does
answer
yes
to
the
first
question
that
they're
considering
these
kinds
of
different
approaches,
what
what
do
the
authors
here
want
to
have
happen
that
this
is
a
working
group
document
that
is
sort
of
like
a
use
case
document?
Or
is
this
just
a
standing
draft
that
eventually
will
go
poof
and
once
the
protocols
are
developed
there,
it
doesn't
seem
to
fit
into
charter.
So
I
was
wondering
what
what
your
plan
was.
C
L
L
If
the
working
group
willing
to
consider
optimizations
for
reducing
the
concentration
of
information,
I
think
that
the
word
optimization
implies
the
ability
to
to
evaluate
an
objective
function
to
tell
up
from
down
and
I
think
we
really
don't
have
that
level
of
understanding
about
the
implications
of
of
where
these
queries
go.
So
instead
of
optimizations
for
reducing
the
concentration,
I
would
just
say,
configurations
that
alter
the
concentration
and
leave
it
to
a
future
future
group
or
to
users
and
implementers
to
determine
what's
what's
optimal
and
on
describing
the
operational
impact
of
those
optimizations.
L
Similarly,
I
think
that
we
should
inspect,
we
should
not
speculate.
We
can
certainly
describe
obvious
interactions
with
other
existing
systems,
but
I.
Don't
think
that
we
should
guess
at
higher
order
effects
that
they're
likely
to
have
I
do
think
that
there's
real
potential
work
here
for
the
IRT
F
privacy
enhancements
research
group
to
try
to
figure
out
what
happens
when
DNS
queries
are
distributed
or
concentrated
in
different
ways.
Thank
you.
C
Thank
You
Ben
I
just
wanted
a
quick
note.
We
have
people
still
left
to
go
in
the
queue
and
we
just
hit
half
past
the
hour.
I'm
not
going
to
cut
you
off
right
now.
But
if
you
could,
please
keep
your
comments
brief.
We
do
have
a
little
bit
of
buffer
room
built
into
the
schedule
and
so
for
kind
of
extended
thoughts
and
might
occur.
I
would
save
them
towards
the
end
of
the
meeting.
Thank
you,
and
so
next
up
is
Sean.
Sanjay
Mishra.
M
Yes,
this
is
Sanjay,
but
I
did
thanks
for
the
presentation
and
I
think
the
questions
that
you
have
all
three
are
very
valid
questions
and
something
I
believe
fits
with
the
charter
of
the
group.
So
certainly
the
the
group
should
be
looking
at
all
these
three
important
issues.
I
have
looked
at
the
draft
earlier,
but
I
I
can't
you
know.
I
have
to
look
back
again,
but
I
wanted
to
ask
if,
if,
if
you
have
had
a
chance
to
see
how
they
distributed,
resolvers
would
impact
on
the
latency
on
on
the
queries.
E
So
I
think
it
definitely
would
by
the
work
of
the
working
group
at
some
level,
but
I'm
not
sure
that
it
would
be
distinct
in
in
looking
at
this,
as
opposed
part
of
the
overall
set
of
work
items
of
the
working
group
to
consider
when
you're
over
particular
a
policy
characteristic
and
there's
a
really
pessimal
latency.
What
do
you
do?
I
think
that's
a
question
that
the
working
group
will
have
to
answer
more
broadly
than
just
in
this
context.
M
C
N
So
I
think
that,
like
there's
a
bunch
you
sort
of
raising
here,
Ted
I,
think
there's
a
there's
a
there's.
An
interesting
problem
in
here
speaking
turn
trying
trying
to
climb
out
of
the
presentation,
which
is
say
you
have
a
bunch
of
apparently
equivalent
resolvers
how
you
to
manage
your
queries
for
privacy
and
I.
Think
that
that
section
that
that
section,
I
dropped
is
pretty
interesting
and
in
particular
a
lot
of
things.
People
obviously
might
want
to
do
like
are
really
terrible.
So
it's
like
really
good
to
have
that
pulled
out.
N
I
guess,
I'm,
not
sure
I
mean,
is
interested
in
the
questions
you're
raising
on
this
slide
on
on
in
part,
because
you
know
some
of
them
seem
like
not
really
the
questions.
The
this
draft
raises.
I
think
the
best
place
for
this
draft
would
be
to
be
an
analysis
draft
which
is
it
the
analysis.
Answering
the
question
which
I
just
indicated,
I
think
this
sort
of
the
the
questions
of
like
where
the
drafts
are
like,
where
the
resolver
like
not
really
equivalent,
is
like
really
hard
but
I.
N
Think
about
and
I'm,
like
a
huge
fan,
try
to
reason
about
it.
The
on
I
just
want
to
laugh
like
you
know
so,
I
started
tiny
Polly
said
you
know
we
should
think
about,
like
you
know,
treating
the
network
resolvers
default
I'm.
Please
don't
say
that
like
this,
just
that
is
called
bias
about,
like
the
fact
that
we
things
of
don't
we
being
not
the
way
things
necessary
should
be.
E
Thanks
feedback
I'll
just
note
that
there
are
some
cases
in
which
we
can't
assume
that
the
set
of
DNS
result
or
rate
yeah,
and
so
you
may
two
different
things
you
have
to
worry
about
is
like.
Is
this
a
condition
in
which
I
have
to
go
to
a
resolver,
because
it's
the
only
one
that
can
give
me
an
answer
which
is
a
classic
split,
DNS
problem
or
okay?
Now,
I,
don't
have
that
problem,
and
now,
in
the
second
stage
of
analysis
or
where
medicine
is
I,
can
now
take
into
account
that.
E
C
O
O
The
second
point
is
that
the
current
model
of
using
a
stub
resolver
in
the
home
requires
trust
in
that
for
order
by
outside
the
home.
All
recursive
have
no
visibility
of
the
individual
clients
inside
that,
because
they
only
see
the
aggregated
view
moving
to
client
using
additional
resolvers
outside
the
current
Network
implied
sharing
that
per
client
identification
with
those
resolvers
so
that
that's
a
privacy
lost
in
some
sense,
whether
it's
an
issue,
it
needs
more
exploration,
but
I
do
accept
that
if
the
local
sub
resolver
is
insecure
or
compromised.
A
H
Right,
thank
you
very
much,
so
this
is
going
to
be
an
update
on
some
of
the
thoughts
we've
been
having
around
draft
that
we
presented
last
time
in
deprived
and
in
the
ABCD.
Both
I
apologize,
I
haven't
actually
updated.
The
draft
yet,
but
I
did
want
to
have
this
discussion,
especially
in
light
of
some
of
the
stuff
we
were
talking
about
in
the
last
presentation.
H
Next
slide,
please
so
I
just
drew
a
couple
pictures
here
that
can
help
us
talk
about
this
area.
So
here
is
what
I'm
describing
as
like
a
status
quo
model.
We
have
multiple
devices,
they
each
have
their
own
local
DNS
server.
If
they're
on
the
same
network.
This
would
be
the
same
one
and
they're
reaching
out
to
different
websites
or
other
resources
as
they're
resolving
these
names.
The
next
slide.
H
So
when
we
go
to
a
model
that
we
have
an
one
or
some
centralized
list
of
trusted
remote
resolvers,
we
imagine
now
that
we
are
not
using
local
infrastructure.
We
have
some
remote
server
or
a
dot
server
as
it
may
be.
We
do
all
of
our
resolution
there
and
then
we
get
to
the
same
servers
at
the
end
of
the
day.
So
this
definitely
has
some
benefits
of
not
exposing
to
the
local
resolvers,
but,
as
was
throughout
the
last
conversation
you
may
be.
This
is
centralizing
more
information
onto
that
one
server.
H
We
need
to
make
sure
we
can
trust
that
external
resolver
well,
and
it
also
doesn't
change
any
of
the
stance
about
what
is
exposed
about
the
and
web
service
that
we're
getting
to
next
slide.
Please
all
right,
so
we
can
also
have
multiple
servers.
I
think
when
we
talk
about
multiple
resolvers
here
there
is
a
big
question
of
how
do
we
know
when
we
should
use
them?
If
we
have
multiple,
there
are
different
strategies
that
you
could
take.
You
could
just
distribute
it.
It
could
be
up
to
the
client,
but
next
slide.
H
What
we
are
discussing
in
this
document
is
trying
to
couple
the
notion
of
which
resolver
we
use
with
which
names
we're
trying
to
access
now.
This
does
require
some
bootstrapping
or
axe
figuring
out
what
your
names
are
in
general,
but
what
I'm
accessing
names
within
a
particular
domain,
let's
say,
for
example,
comm
and
I
have
lots
of
sub
resources
on
example.com.
That
may
give
more
information
about
what
I'm
doing
it
seems
like
one
of
the
best
privacy
stances
and
efficiency
stances
in
general
is
to
have
that
information
centralized
with
the
entity
entity
in
quotes.
H
H
So
this
is
one
approach
you
could
have
to
how
to
use
multiple
remote
resolvers.
So
in
general,
why
are
we
interested
in
designating
resolvers
for
domains?
So
the
argument
here
is
that
having
the
same
entity
terminate
your
TLS
or
HTTPS
connections
also
terminating
gordo
gives
you
good
Ben.
It's.
It
does
reduce
the
number
of
entities.
H
That's
seeing
the
names
that
you're
accessing
for
a
given
client
IP
address,
assuming
that
you
have
to
talk
to
this
server
anyway,
at
the
end
of
the
day,
and
while
it
is
true
that
this
entity
that
you're
resolving
to
is
going
to
see
many
resolutions
for
things
under
example.com,
for
example,
it's
also
the
entity
that
is
serving
the
names,
whereas
at
least
related
to
that
entity.
So
it's
probably
aware
of
these
clients
anyway,
it
also
becomes
easier
to
have
optimizations
later.
H
So
if
we
want
to
be
able
to
have
a
client
upgrade
its
connection
from
a
doe
connection
into
a
normal
TLS
connection,
let's
say
goal
at
some
point
was
able
to
do
doe
onto
one
of
its
servers
and
then
I
could
just
upgrade
into
another
connection
having
a
notion
in
which
I
know
that
I
should
be
doing.
My
resolutions
to
the
server
is
a
beneficial
thing
next
slide.
H
That
knows
is
authoritative
for
that
domain
and
the
reason
we're
using
this
is
that
it's
the
same
mechanism
that
we're
already
going
to
have
to
request
for
getting
the
encrypted
TLS
client,
hello,
the
yes
and
I,
previously,
that's
being
renamed.
So,
if
I'm
already
requesting
that
it's
nice
to
bootstrap,
also
knowing
that
there
is
a
doe
resolver
that
can
do
for
more
specific
queries
in
the
future
and
note
that
this
is
kind
of
involving
a
bootstrapping
step.
H
H
So
here
is
to
I
have
information
that
we
can
get
specifically
from
a
doe
server
off
of
a
JSON
blob
that
we're
just
using
the
provisioning
domain
existing
blob
here.
So
if
we
access
the
specific,
well-known
URL
off
of
that
server,
I'm
specific
to
this
DNS
URL
template,
we
can
get
more
information
that
can
be
extensible
about
this
server.
H
H
H
This
designation
does
need
to
be
trusted
in
some
form
and
that's
why
I
want
to
spend
the
rest
of
this
time
going
over
if
we
do
have
DNS
X
signed
records.
That
we
believe
is
a
good
indication
that
the
owner
of
this
domain
and
the
entity
managing
it
is
aware
of
the
dos
or
her
or
the
dot
server
that
you
are
designating
and
therefore
we
have
some
reasonable
reason
to
believe
that
this
designation
should
be
trusted,
and
this
could
be
done
on
the
local
network
as
well.
H
So
if
your
local
network
actually
did
own
Comcast
phone
Xfinity,
let
you
know
that
the
local
resolver
was
indeed
authoritative
for
that
and
designated.
However,
we
have
certainly
gotten
a
lot
of
feedback
and
we
recognize
that
it's
not
always
possible
to
deploy
DNS
SEC
easily,
especially
for
very
large
deployments.
That
may
come
at
some
point,
but
that's
not
an
easy
bar
right
now.
H
So
we've
been
looking
at
other
mechanisms
to
get
a
similar
form
of
trust,
so
in
the
same
way
that
we
want
to
have
a
relationship
in
which
the
owner
of
the
name
is
pointing
back
to
the
DOE
template
or
whatever
other
encrypted
resolver
you
have.
We
want
have
some
proof
that
the
owner
of
this
name
is
pointing
back.
So
the
proposal
here
is
that
we
could
have,
in
my
extended
information
about
me,
resolved
or
a
hint
that
it
claims
that
it's
designated
by
example,
calm.
But
then
we
can
go
independently.
H
Do
in
separate
resolution
for
the
top-level
domain
of
example
comm
without
using
the
DOE
server
at
all.
That's
it
do
TLS
two
there
and
if
we
see
that
indeed
a
well-known
URL
at
example.com
says
yes,
this
is
my
doe
server.
Then
we
have
some
reason
to
trust
this.
It's
more
round-trips
to
do
this
bootstrapping,
but
it
can
get
a
similar
effect
to
DNS
SEC
next
slide.
Please.
A
H
A
A
A
N
I
mean
this
is
this:
is
cool
I
want
to
make
two
points,
one
trivial
and
tentacle,
and
one
more
substantial
on
the
trivial
on
tentacle
one?
Is
you
indicate
that
this
is
the
same
information
as
is
needed
for
es
ni,
and
that
is
a
some
level
true,
but
at
some
level
it's
false
and
a
level
up
which
is
false
is
that
es
ni
does
not
really
require
the
data
to
be
authenticated
on.
N
This
is
kind
of
counterintuitive
it
as
covered
in
the
draft,
in
quote
yes
and
I
draft
quite
a
bit,
but
the
executive
summary
is
the
points
you
controlled.
The
DNS
then
like
SMI
informations,
effectively
lost,
because
you
can
like,
for
instance,
return
a
unique
address
for
every
s,
ni
and
so
like,
but
instead
of
having
the
the
DSi
cryptokeys,
if
any
gate
isn't
very
important
where's.
N
So
what
happens
is
that
the
structure
of
this
is
basically
that
on
because
you're
painting
people
to
whatever
they
happen
to
get
on
if
the
CD
ends
both
do
this,
it's
very
easy:
Anna
participation,
we're
basically
on
temporary
traffic,
shifts
persistent
or
hard
to
fix.
In
particular
like
imagine
bees
down
and
a
is
covering
all
the
traffic,
then
they
like
it
almost
impossible
traffic
back
to
be
until,
like
all
these
things
expire,
so
I
think
I
floated
this
to
you
before
and
I'm.
C
H
K
N
Yeah
so
I
mean
so
my
assumption
is
that
the
way
you
will
typically
deploy
this
will
be
that
on
the
every
every
every
person
in
the
limit,
every
Wars,
like
service
providers
serving
on
a
domain
will
one
advertise
that
it
went
will
handle
the
the
dance
for
at
least
I
thought
domain
right,
because
that's
where
you
have
the
maximum
privacy
benefit.
So
imagine
you
in
the
situation
where
so
do
me
sample
comm
is
served
by
cDNA
and
CD
MB
and
they
both
advertise
on.
N
You
know,
records
that
say:
hey
look,
I'm
like
the
person
who's
responsible
for
this
right
and
that's
especially
obvious
in
the
in
HTTP
case,
which
you
indicate
here
on
and
so
on,
and
so
my
concern
is
that
that
makes
the
the
traffic
allocation
any
given
time
extraordinary,
stable
and
hard
to
change.
So,
in
particular
on
like
say
I
all
my
traffic
goes
to
cDNA
on
and
then
I
want
your
new
CDN
be
well
that
I
takes
a
long
time.
So
all
these
records
have
to
expire
and
on
so
I
think
I
need
some
story.
N
H
I
I
think
that's
something
that
I
do
want
to
get
more
input
from
the
group
on
I
see
two
different
deployment
solutions
to
this
area.
One
is
that
a
given
entity
that
is
distributing
its
traffic
between
multiple
CBN's
could
have
one
single
notion
of
its
doe
resolver,
that's
in
charge
of
splitting
the
traffic
between
the
two,
that's
kind
of
like
this
virtual
entity.
That's
not
necessary
the
CDN
itself,
but
some
intermediary.
That's
working
on
behalf
of
the
domain
owner
from
both
sides.
H
But,
alternatively,
there's
no
reason
that
when
I
request
a
HTTP
service
record
or
a
given
name,
it
can't
have
answers
back
to
me
of
saying
that
it
actually
has
two
different
designated
servers
that
both
check
out,
and
perhaps
we
use
the
priorities
in
those
records
to
kind
of
do
the
weight
balancing
of
who's
going
to
wear
so
I
think
there
are
different
ways
we
can
look
at
it,
but
we'd
want
some
more
CDN
input
on
the
details
here,
all
right.
So
to
finish
the
slides
out.
H
This
is
just
demonstrating
the
scenarios
that
we
have
specific
to
the
DNS,
SEC
validation
or
the
lack
of
DNS
SEC.
So
in
the
case
in
which
we
are
able
to
get
a
DNS
ex
signed
record
that
says,
example.com
designates
the
valid
doe
server
everything's
fine.
We
can
do
our
doe
queries
directly
to
that
server
for
everything
under
example.com
from
that
on
next
slide.
Please.
H
The
concern
is
that
if
you
have
unsigned
records,
we
of
course
can't
trust
those,
because
anyone
could
just
put
example.com
designates
attacker
doe
server
and
then
all
of
a
sudden,
I
use
that
and
you're
redirecting
my
traffic
next
slide,
please
so.
The
mitigation
that
we're
talking
about
using,
which
does
have
more
round
trips,
is
that
I
have
an
unsigned
record
for
example.com.
H
It
says
if
it
says
a
valid
doe
server.
I
can
connect
to
that
doe
server,
not
request
any
user
traffic,
but
simply
do
an
informational
query
onto
it
to
get
its
blob
in
that
it
could
say.
Yes,
the
example
that
comes
trust
me.
We
then
go
do
a
query
separately
using
another
DNS
resolution
source
behind
example.com
and
validate
that
example.
To
come,
indeed
designates
the
valid
doe
server
next
slide.
So
the
attacker
case.
In
this
case,
we
would
if
they
tried
to
do
the
same
thing
unless
the
valid
server
with
the
TLS
server.
H
C
C
Q
Graffiti,
if
the
tracker
is
concerned
for
the
case
where
you
try
to
have
the
people
will
not
be
viable
that
that
domain
you
can
set
that
on.
If
there
was
a
way
to
do
that,
based
upon
the
name
that
was
in
ze
on
the
service
domain
name
of
the
GPS
service
record,
to
the
target
of
that,
since
it
would
be
distinct
person
that
might
address
that
issue,
I'll
put
an
example
into
the
into
the
Jabra
shop.
C
P
Hi
Tommy
he's
a
very
slick
way
of
doing
discovery,
the
one
that
you
didn't
touch
on
them
in
the
presentation
how
and
I
as
a
user
express
my
preferences,
because
at
the
moment
it
looks
like
the
machines
taken
control
for
me
if
I
want
to
curtail
it
from
just
going
wherever
it
wants
to.
How
am
I
I
say:
I
only
want
to
go
to
particular
resolvers
or
only
those
week,
particular
policies
rather
than
let
it
fly
wherever
it
sees
fit.
H
Yeah,
that's
a
great
point
and
a
great
question:
I
think
that
is
something
that
the
working
group
does
need
to
talk
about
and
I
think.
Well,
it's
like
the
item
three
on
the
Tartar
kind
of
covers
that
this.
What
I'm
talking
about
here
is
purely
about
the
discovery
and
discovery
of
information,
not
at
all
how
it's
used.
I
think
the
client
always
needs
to
retain
the
authority
to
ignore
the
information
it's
always
going
to
have
that
ability.
C
P
R
Then,
in
the
current
scenario,
because
if
you
ask
for
come
everybody
up
to
shame
pretty
much,
if
you
ask
them
being
a
regular
resolver,
what
the
authority
for
that
guess
is
the
IP
address
of
the
resolver,
whereas
in
this
case,
if
you
have
a
double
dot
server
at
a
higher
level
domain,
then
you'll
get
sort
of
all
the
queries
from
all
the
clients.
So
you
can
actually
connect
the
client
population
and
do
something
with
it.
That
might
be
something
to
think
about
to
maybe
improve
on
yeah.
H
And
that's
definitely
a
good
point.
We
that's
why
to
the
earlier
discussion
we're
having
of
you
know,
when
do
we
distribute
our
resolutions?
I
think
we
need
to
take
into
account
both
which
resolvers
we're
using,
but
also
the
ultimate
connections
were
making.
So
if
you
were
doing
resolutions
without
ever
making
connections
I
to
the
same
entity,
I
think
that
definitely
is
a
problem.
H
I
think
if
we
can
have
a
way
to
limit
it,
such
that
for
the
names
under
google.com
I
only
I'm
talking
to
the
Google
Doh
server,
presumably
is
already
in
a
place
in
which
is
receiving
these
TLS
connections
later.
So,
hopefully,
it's
not
able
to
gather
more
information
because
it's
about
to
receive
those
names
anyway,
but
that's
something
I
continue
to
be
concerned.
Yeah.
B
F
Hear
me
so
Tommy
I'll
try
to
be
quick.
So
the
question
is
this
works?
Well,
when
the
DNS
and
the
web
servers
are
operated
by
the
same
entity,
but
for
smaller
providers
where
they
were
outsource
their
DNS.
This
would
actually
result
in
providing
more
information
about
the
client
to
different
entities,
and
my
my
concern
is
that
the
large
websites
are
generally
public.
H
Like
that's,
say:
I
have
something
one-off
website
that
I'm
concerned
about,
and
it's
running
on,
poplar
it's
running
on
GoDaddy
or
whatever.
Those
piece
is
if
the
entity
that
is
authoritative
for
the
resolving
and
the
connections
is
that
CDN,
rather
than
your
particular
website
that
may
have
good
properties.
But
yes,
if
you
are
running
your
own
server
completely
independently,
then
we
do
need
to
be
concerned
about
that
case.
C
So,
first
relaying
from
Ben
sports
on
Jabbar
I
understand
how
the
scheme
improves
privacy
when
combined
with
oblivious
DNS,
but
in
the
absence
of
oblivious
DNS,
which
is
out
of
scope
for
abd
I,
think
this
is
only
a
privacy
improvement
for
certain
assumptions
about
TTLs
and
some
queries
will
leak
when
TTL
is
expire.
I'd
like
to
see
those
assumptions
clarified
and
see
if
there
is
a
simpler
solution,
such
as
using
long
live,
C
names
I
also
want
some
consideration
about
whether
these
long
details
are
a
tracking
vector.
S
Thanks
for
the
mic,
this
is
Warren
Kumari,
so
someone
I
think
it
was
Tommy.
Pauly
said
that
you
know
we
should
only
use
the
Google
resolver
for
google
names,
which
initially
sounds
like
a
grand
idea,
except
that
I
don't
know
what
a
Google
name
is
right:
there's
Google
com,
there's
Google
user
content,
there's
Gmail
and
there's
thousands
of
other
names
and
so
and
they
say
have
a
way
of
knowing
beforehand
what
names
should
be
mapped
to
a
resolver.
S
H
And
then
I
think
that's
the
strapping
question.
If
we
have
some
oblivious
mechanism
that
we're
doing
the
initial
resolution
over,
then
that's
slower,
but
we
can
trust
it.
Alternatively,
there's
nothing
stopping
you
from
having
a
you
know.
Let's
say
one
trusted
resolver
that
you
use
for
your
default.
Queries.
Do
you
think,
has
good
properties,
but
then,
once
you
learn
that
oh
this
domain
I
didn't
know
about
actually
is
a
Google
name.
Then
you
switch
it
over.
D
J
So
our
scope
for
this
draft
is
how
to
discover
a
dough
and
dot
servers
on
a
private
or
local
network
we're
concentrating
first
on
on
home
networks.
We
have
a
separate
document
that
we're
working
on
for
enterprise
networks,
but
we
wanted
to
hit
the
home
networks
first,
it's
most
relatable
next
slide.
Please.
J
J
So
this
is
showing
a
situation
where
there's
a
managed
CPEs
CPE
managed
by
an
ISP
talking
to
and
on
the
top
diagram
is
showing
talking
to
an
ISP
managed
DNS.
So
like
Comcast
in
the
United
States
is
like
this.
The
bottom
one
is
an
ISP
managed
CPE,
which
is
configured
by
the
ISP
to
go
to
some
cloud-based
resolver
like
a
tete-a-tete
a
due
date,
/
deity
or
over
the
o
h
for
both
of
these
next
slide,
please
and
in
same
situation
with
an
unmanaged
CPE.
J
In
our
document
we
we
discuss
ways
to
discover
this
information
so,
of
course,
for
classic
DNS
over
53.
The
existing
DHCP
and
Ra
options
are
what
are
used.
The
yellow
shows
that
what
we're
proposing
is
that
reference
identifiers
discussed
in
the
document,
forgetting
the
authenticated
domain
name
and
then
the
URI
templates
are
also
discussed
in
the
document.
How
to
obtain
those.
J
J
This
works
by
having
a
list
of
what
the
verified
resolvers
are
and
when
we
connect
to
a
resolver
that
were
given
by
the
local
network,
we
verify
the
signatures
that
we
can
obtain
from
its
certificate
that
we
get
over
TLS
next
slide.
Please
and
it
shows
the
pre
configuration
that
is
that
occurs
for
the
verified
resolver
next
slide.
J
We
also
discuss
a
situation
where
the
in
the
draft,
where
the
resolver
or
I'm
sorry,
where
this
server
is
obtain
a
certificate,
a
signature
from
a
certificate
authority.
That
is
an
auditor.
So
it's
separate
from
the
operator
next
slide,
please
the
other
things
in
the
draft,
and
we
may
want
to
discuss
this
and
pull
this
out,
because
it's
probably
appealing
for
some
other
situations,
but
we
need
to
discuss
it
more
for
sure
is
when
the
ISP
is
operating
a
DOS
server.
J
It
may
want
to
reflect
back
or
send
back
those
queries
to
the
ISP
operated
CPE
to
help
shed
the
load
and
get
faster
resolution
inside
the
home,
so
it
doesn't
have
to
suffer
going
up
the
up
and
back
down
the
access
link.
So
the
mechanism
that
we
have
in
the
document
next
slide
please
on
how
to
do.
That
is
to
do
an
HTTP.
J
It
knows
and
manages
the
certificates
on
there
as
well,
so
that
can
be
a
a
doe
server
that
is
signed
by
the
ISP
or
side
by
the
auditor
in
which
direction
we
go
through
and
go
forward
with,
but
this
seemed
like
a
nice
technique
for
getting
the
ISP
DOS
server
offloaded
in
much
the
same
way
that
happens
today
with
resolvers
in
it
with
dns
mask
running
and
residential
CP
next
slide,
please
and
those
servers
and
uri
templates.
So
this
describes
why
we
need
them
and
how
we
propose
to
get
them.
This
is
a
pending
issue.
J
There's
been
some
discussion
on
the
mailing
list
about
best
ways
to
do
this.
The
best
ways
to
move
forward
on
this
next
slide
talks
about
some
trade-offs
in
different
mechanisms
that
we've
considered
in
the
document,
and
this
is
something
we
need
some
more
discussion
on
the
mailing
list
and
in
the
working
group
for
part
of
the
reason
I'm
rushing
through
the
presentation,
so
we
can
get
some
more
feedback
on
this
slide.
J
Please
one
of
the
values
of
having
a
DOS
server
or
d-o-t
server
running
in
the
home
is
that
it
can
identify
the
different
clients
inside
the
house,
because
you
can
see
the
MAC
address
in
the
IP
address
of
those
devices
and
identify
it.
It's
a
child's
device
or
a
parent's
device
and
provide
different
filtering
either
for
content
or
for
malware
for
that
device
and
IOT
device
needs
different
filtering
than
a
its
PC.
J
So
this
allows
that
to
occur.
If
the
resolution
is
at
the
ISP,
it's
more
difficult.
There's
ways
to
accomplish
that,
but
it's
more
difficult
to
accomplish
that
because
of
the
nap
that
is
typically
performed
at
the
residential
device
for
ipv4
next
slide.
Please
there
is
an
implementation.
That's
done
privately!
We
don't
have
that
available
publicly.
Yet
that
does
nearly
everything
that
is
described
in
our
internet
draft
and
then.
Finally,
the
last
slide
is
the
next
slide.
C
J
T
Thompson,
please
so
I
I
think
there's
a
there's,
an
interesting
question
there
and
in
terms
of
whether
we
trust
a
particular
server,
and
it's
kind
of
sad
that
we're
at
the
point.
We
have
lists
at
end
points,
but
my
question
was
more
about
the
your
expectations
about
updating
CPE.
My
experience
with
all
of
these
things
is
that
CP
doesn't
get
upgraded
and
so
assuming
that
something
like
this
would
happen
in
CPS.
Oh,
that
such
that
it
brew
provides
the
dhcp
options
that
you're
talking
about
seems
a
little
unrealistic.
T
J
R
Hello,
so
thanks
a
lot
for
that.
It's
the
kind
of
CP
he
angled
was
something
that
I
always
thought
a
lot
about
and
I
quite
contrary
to
what
my
predecessor
said
is
that
there
are
ISPs
that
managed
their
CPE
and
on
these
devices
there
are
frequent
updates.
These
devices
are
managed.
You
can
kind
of
rely
on
them
being
up
to
speed
and
being
there
for
you
for
the
subscriber
now
thing.
R
J
R
U
What's
hard
to
cook,
please
all
right,
I
guess
make
sure
you
hear
me.
Yes,
ok,
you
see
what
important
takeaway,
if
based
on
academic
research
done
lately
in
terms
of
TTLs,
is
that
if
you
move
resolvers
into
home
devices
and
with
the
incredibly
short
T
tails
that
are
out
there
in
the
field
today,
which
are
mostly
around
you
know,
five
minutes
sometimes
they're
up
for
an
hour
but
common
practices.
C
D
J
So
this
is
a
presentation
on
DNS
server
selection
with
an
assertion
to
token
so
here
we're
trying
to
who
we're
trying
to
decide
which
DNS
servers
we
want
to
pick
and-
and
it's
a
it's
a
simple
pick
not
like
what
Ted
was
talking
about
earlier,
where
we
rotate
through
but
but
as
static
choice
and
in
next
slide.
Please.
J
So
what
we
want
to
add
to
the
the
selection
is
resolve
our
information
about
its
capabilities.
So
whether
or
not
it
does
DNS
filtering,
for
example,
and
to
use
that
in
combination
with
existing
pbd,
like
techniques
to
decide
which
server
to
talk
to
him.
So
then
we
also
would
like
notification
when
the
policy
changes
or
when
the
DNS
filtering
is
reconfigured.
So
if
the
filtering
is
turned
on
or
turn
off,
is
that
the
client
get
a
notification
that
because
it
now
may
want
to
change
to
a
different
DNS
server?
J
That
follows
the
policies
that
it
likes
or
has
the
filtering
that
it
likes,
and
we
also
want
a
way
for
the
human
and
also
for
the
computer
itself
to
identify
and
locate
the
privacy
policy
statement
in
order
to
do
something
useful
with
that
and
we're
not
talking
about
parsing
it,
and
we
kind
of
talked
about
that
before,
but
we're
not
talking
about
parsing
it
we're
leaving
that
up
to
the
end-user
who
we
all
know,
don't
read
the
end-user
license
agreements,
but
that
still
seems
to
be
the
best
limit
that
we
can
do
next
slide.
Please.
J
So
currently
we're
we're
proposing
making
these
choice
on
filtering
capabilities
and
which
is
in,
is
filtering
for
malware
and
DNS
filtering
for
for
policy
like
objection
or
content,
and
things
like
that
for
again,
a
home
network,
server
situations
and
then
also
a
key
name:
it'll
minimization,
and
whether
or
not
the
DNS
server
you're
talking
to
supports
that
slide.
Please
and
the
policy
attestation
is
a
signature
by
whoever
runs
the
DNS
server.
So
if
Comcast
is
running
a
DNS
server,
they
would
sign
this
and
then
they
may
have
an
outside
auditor
who
validates
that?
J
J
And
the
important
point
is
that
last
bullet
is
that
the
DNS
client
is
configured
to
trust
the
signer
of
the
pad
object,
so
the
either
that
is
their
ISP
Comcast,
for
example
the
auditor.
If
they
like
what
the
auditor
has
done,
you
don't
Ernst
and
Young,
or
whoever
might
be
the
auditor
that
validates
that
next
slide
please.
J
This
is
just
the
mechanics
of
the
privacy
assertion
token
and
how
we
sign
that
in
that,
in
the
issues
of
time,
let's
jump
to
the
example
in
the
next
slide.
Please-
and
this
is
an
example
of
a
DNS
server
that
is
doing
malware
walking,
but
it's
not
doing
any
policy
block
blocking
privacy
URL
that
is
accessible
for
the
easier
to
look
at
and
where
the
auditor
and
and
their
URL
information
is.
J
The
privacy
taekman
URL
is
something
human
readable.
The
the
high-level
idea
here
is
changes
to
that
can
be
noticed
when
we
connect
to
it
or
we
get
the
push
and
users
can
review
that
information
and
decide
if
the
privacy
policy
and
the
filtering
agrees
with
what
they
want
to
do
and
then
add
that
DNS
server
to
their
list
of
approved
DNS
servers.
That
is
then
used
in
selection
next
slide.
Please.
C
I
I
J
J
B
J
No,
we
just
thought
the
push
was
kind
of
nice.
I
agree
that
the
pushes
is
kind
of
risky.
The
device
could
be
asleep
all
sorts
of
other
issues
with
it
not
being
able
to
see
that
push.
Certainly,
we
expect
each
time
that
connection
to
the
server
occurs.
You
know
when
you
join
the
network
that
this
information
would
be
retrieved,
but
yeah
TTL
seems
like
a
nice
way
to
solve
that.
Thank
you.
V
I
just
wanted
to
mention,
since
it's
in
the
references,
but
you
didn't
specifically
say
it-
that
there's
guidance
on
creating
a
privacy
server
policy
in
the
deprived
server
privacy,
server,
BCP
draft,
that
is,
with
the
IAS
G
now.
So
there's
specific
it's
examples
of
how
you
might
write
one
for
both
endo
and.
W
Here,
can
you
hear
me
yeah
so
next
slide,
so
the
DNS
resolver
discovery
protocol
next
slide.
So
basically,
the
motivation
is
that
at
a
genus,
I
mean
DNS.
Resolving
service
can
be
achieved
using
different
results,
so
different
identities
and
over
multiple
transports
and
each
of
those
resolving
service.
We
may
also
provide
some
different
services
like
filtering
and
so
on.
W
W
So
the
protocol
needs
to
may
be
used
by
a
DNS
client
and
that
dream
is
fine,
maybe
using
the
regular
DNS
or
the
dot
or
doe
and
discover
the
various
revolving
services,
as
well
as
resolving
services
may
use
this
protocol
also
to
to
advertise
DNS
clients
and
other
preserving
services
are
available.
That's
the
first
requirement.
The
second
one
is
that
yeah
I
mean
the
product
must
be
able
I
mean
the
discovery
should
be
dynamic
and
concerned,
local,
invisible,
preservers
and.
W
Just
to
mention
that
I
mean
it
could
be
extended
with
what
is
being
described
in
the
doctrine,
then
it's
I
mean
discovery
when
I
think,
but
we
would
like
the
output
of
this
discovery
to
be
used
carefully
by
the
dense
client.
So
the
draft
is
not
discussing
that
at
all
how
selection
processes
are
operating
but
I'm
we
do
I
mean
the
discovery
mechanism
should
be
made
so
that
the
selection
process
can
be
automated,
involve
the
Janus
client
as
well
as
maybe
the
other
party,
which
is
the
resolving
service.
W
We
would
like
that
the
output
could
also
presented
to
the
end
user
and
so
be
understood
by
that
end
user,
as
well
as
requirement.
Six,
which
is
may
be
the
end
user,
just
want
to
be
involved
into
a
subset
of
those
output
provided
by
the
result,
discovery
protocol.
So
at
some
point
he
might
be
able
to
delegate
that
to
the
resulting
service
to
choose
what
the
best
option
and
then
another
requirement
is,
and
if
you
know
you
want
to
look
only
for
resolving
services
that
belongs
to
one
category
instead
of
the
other.
W
Yet
the
information
provided
by
the
the
protocol
should
be
educated
and
I
mean
the
protocol
should
not
distract
the
legacy
protocols
and
should
be
also
be
integrated
by
the
the
currently
used
DNS
clients.
So
these
are
the
requirements
are
used,
the
next
slide
so
I
suppose
we
keep
the
question
for
the
end
unless
someone
is
willing
to
you
jump,
raise
some
questions,
so
the
information
returned
by
the
discovery
protocol
so
I
mean
I'm
I.
Think
one
of
the
important
parameters
discovery
parameters
after
the
identity
of
the
resolver.
W
It's
close
to
the
identity
because
it's
quite
meaningful,
TV
and
user,
it's
close
to
the
legal
entity
in
some
cases
and
though
it's
not
user
friendly,
but
it
could
be
used
as
a
key
to
to
retrieve
information
that
you
would
like
to
present
some
case,
and
we
believe
that
the
end
user
has
to
select
a
result.
It
needs
to
be.
You
need
to
have
some
familiarity
with
the
DNS
names,
so
it's
pretty
fine
host
name.
W
On
the
other
hand,
we
don't
believe
it's
it's
it's
a
meaningful
information
and
we
don't
expect
it
to
be
presented
to
the
end-user
and
then
for
an
identity.
As
I
said
to
these
that
that
identity,
we
have
resolving
parameters
which
concerned
transpose
TLS.
You
right
template
specific
services
like
filtering.
V
W
W
Next
slide,
DNS
being
the
language
between
I
mean
notice
to
invite
the
DNS
client,
as
well
as
by
the
resolver,
and
so
when
the
discovery
protocol
is
performed
by
the
client.
The
first
thing
is
to
discover
the
resolving
domains,
local
and
global,
and
then
discover
the
dip.
The
various
flavors
of
the
resolver
within
that
resolving
domain,
when
performed
by
the
resolver
I
mean
it's
like
a
push.
It
should
send
this
information
back
during
a
DNS
exchange,
for
example,
next
slide
so
to
discover
the
global
domain
well
using
a
similar
idea.
W
Then
then
the
DNS
SD
we're
using
a
brow
browsing
domain
and
a
special
domain
which
would
be
DNS
da
tarde
en
esta
tarde
par,
and
this
specific
domain
name
is
going
to
list
all
the
globally
available
resolver,
not
the
resolver,
the
preserving
domains
and
therefore
the
local
domain.
The
local
preserver
and
usually
you've
been
provided
an
IP
address
through
a
DHCP
or
brooder
advertisement.
So
you
simply
do
reverse
DNS
resolution
to
that
IP
address
and
you
find
post
name
dot
resolving
domain
and
that
domain
should
be
the
one
associated
to
the
resolver.
W
So
if
you
want
to
discover
all
the
different
flavors
under
resolving
domain,
so
in
this
case
T
the
domain
is
example.com,
so
we
want
to
discover
the
dinner
service.
So
you
you,
you,
you
add
the
enters
called
DNS
dot
example.com
and
you
do
an
SV
CB
request.
So
you
have
the
introductions
to
all
the
different
flavors.
So
here
we
mentioned
the
legacy
resolver
the
example
choice
and
the
others
flavors
using
doe,
for
example.
W
W
F
Is
beneath
here,
can
you
hear
me
yeah,
hi
Daniel?
This
is
interesting.
The
question
and
it
may
tie
in
with
like
the
resolver
info
draft,
which
Paul
and
I
wrote,
but
the
one
thing
I
do
not
understand
here,
maybe
I'm
missing.
Something
is
how
is
the
list
of
resolvers
generated
and
who
is
responding
to
the
queries
with
this
information
to
the
client.
F
W
W
So
which
slide
your
walkers
they're
not
numbered,
so
at
this
I
don't
know
who
is
gonna,
take
care
of
that,
but
it
could
be.
The
I
mean
the
Ayana,
for
example,
and
I
mean
globally
available
services
would
be
represented
by
resolving
domains.
So
you
could
have
one
that
one
that
one
and
I
have
google.com
or
I
mean
all
those
domains.
So
that's
that
was
the
intention.
W
W
C
W
C
C
D
Kyra
Hollis
John
here
and
just
a
comment
on
having
a
global
list
of
servers.
If
you
define
a
business
idea
where
someone
has
a
mana
monopoly
of
deciding
who
gets
to
play
and
who's,
not
you're
asking
for
a
lot
of
trouble,
we
have
enough
trouble
with
the
root
servers.
You
shouldn't
ask
for
another
list
like
that.
W
D
A
Thank
you
so
there's
a
picture
of
our
audience
for
today,
so
we
have
12
minutes
left
I
would
invite
people
to
either
the
jabber
or
someplace
else
to
you
know,
give
comments
of
them
how
they
thought
this
ran
at
what
worked
and
what,
where
things
can
improve,
because
we
have
a
bunch
of
other
groups
that
are
gonna
meet
later
this
week.
That
can
learn
from
our
experience
via
one
of
the
first
ones,
to
try
this
so
the
intention
in
the
next
couple.
A
T
One
of
the
things
I
saw
in
the
presentations
that
we
had
where
it
was
a
lot
of
concentration
on
the
specifics
of
discovery
mechanisms
without
a
great
deal
of
discussion
about
what
it
is
that
the
the
the
requirements
are
and
I
guess
the
principles
that
are
driving
that
I
think
Dan
got
into
salva,
that
his
presentation,
but
I
would
like
to
see
us
talk
a
little
bit
more
about
what
we
thought.
That
principles
were.
We
saw
Tommy
with
one
approach
we
saw
Daniel
and
down
with
different
approaches
to
discovery.
T
X
Thank
you
hawkman,
please
I.
This
is
Paul
Hoffman,
so
I
was
about
to
say
something
very
similar
to
what
Martin
just
said.
One
of
the
things
that
drove
the
creation
of
this
working
group
was
the
question
of
simply
how
do
I
discover
whether
I
can
upgrade
from
unencrypted
DNS
to
encrypted
DNS
and
I
hadn't.
Seen
that
in
any
of
the
presentations
today,
I
would
be
interested
to
know
if
the
working
group
still
finds
that
to
be
useful,
because
I
would
think
that
that
would
be
easier
than
almost
any
of
the
other
proposals.
Thanks.
G
G
A
G
C
Not
speaking
for
the
entire
rest
of
the
working
group,
but
personally
I
anticipated
being
brought
up
in
kind
of
pervasively
throughout,
you
know
I'm
not
again
no
had.
This
is
a
tale
by
the
way
David
Lawrence.
So
no
hat
on
I'm,
not
you
know
setting
direction
here,
but
this
seems
to
me
to
be
something
that
is
a
kind
of
pervasive
consideration
that,
rather
than
standing
on
its
own
in
a
you
know,
a
separate
document
has
to
be
kind
of
brought
up
in
in
each
of
the
context
that
we're
talking
about.
O
C
I
Okay,
I'll
jump
in
just
four
quick
movements
to
go
back
to
the
document.
Ed
yani
starts
with
the
agenda.
We
need
to
look
at
what
what
us.
In
fact,
it's
good
to
view
an
enterprise
networks
and
maybe
looking
at
won't.
Somebody
have
to
see
something
like
spreading
the
agreement
of
the
treaty
traffic
across
a
bunch
of
different
servers
or
something.
I
P
Yeah,
just
going
back
to
I
think
it
was
Simon's
point
about
the
user.
The
voice
of
the
user
in
this
may
be
making
it
slightly
complex,
the
user
might
be
the
enterprise
network
administrator
or
indeed
the
parent
I,
think
some
of
the
discussion
of
touched
on
out
briefly.
But
we
mean
we
need
to
make
sure
that
this
isn't
just
a
slick
set
of
options
for
clients
that
completely
bypass
the
user
of
the
device
and
assume
that
the
client
is
all-knowing
and
all-seeing
in
this.
C
A
Thank
you,
everybody
for
doing
this
I'm
thinking,
but
pretty
well.
I
was
worried.
First
time
we
tried
this,
so
we
picked
out
a
little
over
200
participants.
We
had
that
one
glitch
with
somehow
preview
would
it
advance
the
next
slide,
what
it
was
being
shared,
but
we
starting
preview
solve
that
problem.
So
thank
you
for
your
patience
and
I'll
see
the
rest
of
you
guys
on
the
list.
Thank
you
very
much.