►
From YouTube: IETF104-DPRIVE-20190329-1050
Description
DPRIVE meeting session at IETF104
2019/03/29 1050
https://datatracker.ietf.org/meeting/104/proceedings/
A
B
B
D
B
B
B
B
Blue
sheets
have
started
around
I,
believe
Suzanne
started
the
passage,
so
please
sign
those
so
that
we
know
what
size
room
we
need
and
we're
not
either
cramped
on
top
of
each
other
or
yelling
at
each
other
from
five
miles
away.
The
next
time
we
meet
agenda
first
thing:
we're
gonna
run
through
the
agenda,
make
sure
we
got
the
blue
sheets
going.
The
first
order
of
business
is
going
to
be
discussions
of
our
stage
two
work.
B
B
As
far
as
that
goes,
we
have
some
some
updates
from
from
the
76
26
biz
work,
as
well
as
the
BCP
op
and
then
new
things
coming
down
the
pike.
We
have
some
some
discussions
on
a
BCP
for
doe
clients
using
dot
for
insecure
delegations
and
how
to
bootstrap
the
DNS
servers.
Does
anybody
have
any
changes
or
modifications
to
the
agenda
that
they
would
like
to
propose.
E
Hi
morning
everybody
so
been
on
myself
and
William
got
together
and
worked
on
something
that
should
cover
the
one
of
the
milestones,
the
so-called
unpublished
document.
So
but
the
purpose
of
this
talk
is
to
give
you
like
a
little
bit
of
a
background.
We
have
a
couple
of
questions
that
we
have
collected
and
after
that
we
really
want
to
go
into
a
discussion
of
how
to
proceed
with
this
document.
E
So,
just
to
give
you
a
background
of
that,
the
TRF
charter
actually
contains
a
work
item
that
says:
develop
requirements
for
rating
confidentiality,
the
DNS
service,
and
that
is
supposed
to
be
in
our
published
document
yeah.
So
we
have,
we
have
taken
the
decision
to
put
it
into
the
put
it
actually
on
a
key
top
page.
So
during
ITF,
as
you
remember,
the
deep
RF
working
group
sessions
of
Katherine,
so
there
wasn't
any
chance
to
discuss
that.
F
E
You
a
quick,
run
okra
about
what
what
the
document
is
about.
We
are
we
actually
listing
existing
and
previous
work.
That
includes
previous
work
from
a
private
group
as
well
as
work
from
other
groups.
We
came
up
with
the
idea
that
the
the
requirement
the
requirements
actually
come
from
three
different
perspectives.
So
one
is
the
user
requirement,
the
user
perspective,
that
user
might
have
a
different
requirement
and
the
other
perspectives
where
the
other
requirements
are.
The
operators,
be
both
recursive
resolvers
as
a
client
and
authoritative
nameservers
to
servers
and
yet
another
perspective
on
requirements.
E
Furthermore,
down
the
document
we
have
a
functional
breakdown
of,
I
would
say
that
ypres
if
a
phase,
two
area
into
those
functional
components,
so
there's
text
about
the
privacy
protection
mechanism,
something
that's
that's,
of
course,
more
trickier.
Here
then,
with
phase
one
is
the
authentication
with
concerns
or
text
about
performance
and
efficiency,
and
some
things
that
came
up
during
the
discussion.
One
is
the
detection
of
availability.
So
how
does
a
server
actually
find
out
that
an
alternative
server
provides
deprived
needle
protocol?
So
I
would
say,
and
something
interesting:
the
end
user
policy
propagation.
E
So
how
does
the
stop
resolver
user
actually
find
out
whether
the
upstream
connection
between
the
recursive
resolver
and
the
authoritative
servers
were
encrypted
or
not
yeah?
This
is
important.
We're
gonna
come
back
to
that
afterwards,
so
the
current
status
is
it's
it's
more
like
an
description
of
options.
It's
not
really
a
hard
requirements
document.
So
so
we
essentially
put
all
the
text
in
that
we
could
think
of,
and
it
doesn't
say
like
a
server
mouse
to
try
and
me
a
client
ought
to,
and
so
the
idea
over
a
tree.
E
The
overarching
question
is:
how
shall
we
proceed
with
this
document?
We
yesterday
we
talked
about
this
a
little
bit
and
we
found
out.
There
are
three
essential
questions
that
I'm
gonna
talk
about
in
a
minute,
but
first,
of
course
please
review
that
one
yeah
please
comment
on
it.
You
can
actually
like
submit
the
pool
request
if
you
want
to
text
edit
or
changed
so
going
further
to
those
three
questions.
E
So
the
question
number
one
to
the
group
is,
as
I
said
before,
the
document
is
currently
rather
a
description
of
options
and
what
functional
areas
do
we
need
to
consider
to
work
on
rather
than
a
hard
list
of
requirements,
yeah,
so
question
number
one
is:
shall
we
modify
the
document
to
twist
hard
requirements
so
must
ensure?
If,
yes,
what
are
these
requirements?
Obviously,
so
that's
the
first
thing
I
would
propose
to
discuss.
E
The
second
question
that
we
came
up
with.
Are
we
actually
set
with
dota2
transport
protocol?
The
document
lists
the
transport
protocol.
Choice
is
one
of
the
dimensions
of
the
design.
Space,
yeah
and
duty
is
baked,
as
we
all
know,
or
a
couple
of
other
options
yeah,
as
we
all
know
as
well.
So
the
question
to
the
group
is:
do
we
want
to
be
settled
on
DNS
or
TLS
as
the
transport
protocol
of
choice
between
recursive,
resolvers
and
authoritative
servers?
E
If,
yes,
do,
we
need
any
changes
to
do
tea
as
it
stands,
a
new
profile
for
authentication.
Of
course,
if
d-o-t
is
not
the
protocol
of
choice,
then
what
else
do
we
use?
Question
number
two
and
question
number
three:
is
the
whole
area
of
end-user
signaling?
So
the
idea
about
that
is
currently
the
the
properties
of
the
upstream
connections
between
recursive,
resolvers
and
authoritative.
Servers
are
opaque
to
the
user,
so
the
user
doesn't
actually
know
whether
his
upstream
connections
were
encrypted
or
not.
E
In
many
other
places,
such
a
similar,
proxying
I
would
three
takes
place.
For
example,
if
you
submit
your
message
where
SMTP
to
someone
that
server
might
or
might
not
use
encryption
when
they
transmit
it
to
the
destination
server,
so
it's
very
similar
problem
to
other
problems
due
to
similar
problems
and
all
protocols.
So
question
number
series:
do
we
do
we
actually
want
or
need
signaling
to
the
stub
resolver?
E
Whether
all
upstream
communication
was
previously
enabled
it's
not
an
easy
problem,
I
think,
because
if
you
think
about
how
many
upstream
servers
might
be
contacted
for
a
single
recursion,
let
me
put
it
that
way.
That's
all
the
question
of
aggregation
in
that,
and,
and
also
the
more
complicated
questions
of
how
do
we
actually
present
it
to
the
user.
How
do
we
get
through
the
API
to
the
actual
human?
That's
the
third
question,
so
I
think
that's
that's!
That's
it
from
my
side
with
regards
for
the
introduction
to
that
document
or
the
problem.
E
B
Yeah
thanks
Alex,
so
what
we
want
to
do
is
we
want
to
focus
on
on
one
question
at
a
time
would
be.
We
have
25
minutes
of
time
to
do
this,
so
what
I
would
suggest
is
we're.
Gonna
go
back
to
the
question
one
and
people
who
have
comments
or
follow-ups
on
question
one
let's
get
those
through
and
then
we'll
move
on
to
question
2,
question
3
and
then
then
we'll
solicit
any
anything,
any
questions
that
people
think
we
might
be
missing.
So,
let's,
let's
start
with
the
the
question
on
hard
requirements:
yeah
I'm,
gonna,.
G
This
is
Daniel
con
Gilmore
a
CLU.
So
it's
not
clear
to
me
whether
this
question
is,
should
we
put
in
should
or
mosques
or
what
should
those
sherds
and
must
be
right
and
I
suspect
that
there
are
people
around
this
room
with
different
opinions
on
what
they
should
be
if
we
decide
to
make
those
changes
so,
but
I'm
also
a
little
bit
unclear
on
whether
if
this
is
the
unpublished
document,
let
me
say:
hey
should
I
mean
it's
published.
G
G
H
G
G
An
authoritative
server
that
offers
private
queries
must
must
be
valid,
like
must
have
its
identity
validated,
and
we
would
list
a
specific
way
that
the
validation
would
work
right.
I
would
want
there
to
be
an
authenticated
way
to
do
that
right.
So
that's
like
the
authentication
should
be
a
must.
What
specific
type
of
an
indication
I
don't
know,
because
we
would
need
to
sort
that
out,
but,
like
that's
an
example
like
I
want
there
to
be
a
way
to
have
a
stricter
opt-in.
I.
I
Steven
and
then
mr.
joe
sympho,
so
I
don't
think
I
don't
care
if
you
use
2119
language
or
not,
you
could
you
could
do
other
things
like
just
move
bits
of
text
down
the
end
and
say
this
used
to
be.
This
is
something
we
kind
of
discard
it.
So
we
don't
have
to
say
you
know
those
things
and
then
I
need
to
go.
I
Reread
the
documents
to
see
which
specific
ones
I'd
have
strong
opinions
on
which
I'll
do
in
a
minute,
but
I
think
generally
I'm
I,
understand
de
cádiz
point
but
I
think
some
more
towards
encouraging
things
that
are
easily
deployable
at
this
stage.
I
think
would
be
a
better
overall
thrust
in
terms
of
the
requirements
that,
rather
than
trying
to
be
aimed
towards
more
strict
with
education,
for
example,
so
in
general
I
think
that
that's
the
direction
I
would
think
it
might
be
better.
I
think.
J
Joe
every
PIR
I
think
the
important
thing
is
that
the
requirements
actually
be
useful
as
requirements.
I,
don't
think
you've
write
in
this
document
just
because
the
milestones
say
you
have
to
you,
I
think
you're
right
there
for
reason.
So
I
think
it's
it's
great
idea
actually
to
not
focus
on
just
whittling,
this
down
to
death
and
and
taking
two
years
to
come
up
with
something
that
can
go
through
the
process
before
you
start
any
other
work,
because
that's
absurd.
B
J
B
L
Yesterday,
okay,
mr.
Shawn
Turner
I
think
it
all
kind
of
agree
with
Stephen
and
it's
a
style
thing
you
can
decide
to
put
Muhsin
Shinzon
or
not.
That's
all
how
you
want
to
write
the
document.
You
can
write
RFC's
or
you
can
write.
Internet
dress
that
become
RFC's.
They
don't
go
2119
language
that
are
still
standards
track,
I
mean
mail.
N
Watson
lad,
I
think
that
this
is
really
a
question
about.
We
should
be
prioritizing
some
of
the
requirements.
There's
some
requirements
in
there
there
are
must-haves
for
certain
communities.
There
are
some
in
there
there
and
nice-to-haves.
There
are
some
in
there
that
it
would
be
good
if
it
happened,
but
we
don't
really
care
I,
think
distinguishing
some
form
of
distinguishing
is
definitely
needed.
Priorities.
C
O
Akamai,
so
I
was
a
bit
confused
earlier
that,
because
we
have
later
in
the
session,
I
think
document
that
addressing
the
solution,
space
on
that
and
having
a
requirements
haven't
already.
I
understanding
now
one
of
the
things
that
I
want
to
say
for
me
would
be
while
mustard.
Whatever
is
we've
done
sort
of
lots
of
efforts
in
having
dns
secured
so
having
the
data
in
dns
secure,
and
we
should
I
think
utilized
that
to
eight
that
protocol
that
we
come
there
yeah.
E
I
have
to
agree
with
you
that,
essentially
in
a
beautiful,
perfect
world,
the
requirements
should
be
done
before
they're,
actually
any
solutions
so
that
we
can
evaluate
the
solutions
against
the
requirements.
That's
not
the
case
here,
that's
where
I'm
careful
about
who
we
actually
need
to
go
that
far
or
do.
We
also
have
two
requirements
in
our
head
anyways,
and
if
that
is
the
case,
can
we
simply
write
them
down
in
five
minutes?.
E
D
Q
E
Q
Q
K
R
Sense,
hello,
made
of
like
power,
deenis
I
like
that
I
like
that
a
lot,
but
what
more
important
to
me
is
that
we
don't
do
a
lot
of
probing.
Nothing,
opportunistic
protocol,
wise
because
I
don't
want
my
resolve
for
spending
seconds
figuring
out
protocol
to
speak
to
somebody,
so
whatever
we
do
make
it
discoverable
without
pain.
Thank
you
and.
S
V
N
F
E
Once
that's
why
it's
ok,
so
I
think
that's
pretty
clear.
We
want
to
go
ahead
with
DoD,
but
we
don't
want
to
preclude
any
potential
future
protocol
yeah.
If
that's
what
the
understanding
is
and
if
we
go
there.
We
actually
want
to
consider
the
implement
this
perspective
that
probing
through
23
different
protocols,
might
be
unfeasible
to
implement
Peter.
Q
E
G
S
I
T
Erik
wine
I
also
sort
of
questioned
its
its
usefulness,
because
if
we
have
this
then
do
we
have
to
have
a
signal
that
says
whether
or
not
Q
name
minimization
was
used
during
the
process
as
well.
You
know
and-
and
you
know,
insert
other
dollar
sign
new
yeah
privacy
feature
it
cooked
like
grow
pretty
quickly.
X
Hi
Pete
Alexis
poverty
is
plus
one
to
consider
it,
but
don't
make
it
a
big
topic
for
therefore,
the
first
draft,
okay
and
I
do
have
a
question
about
the
engine
for
signaling.
What
would
the
end
user
do
with
this
information?
In
the
end,
I
mean
the
question
has
already
been
asked
anywhere
I've
to
the
internet.
So
what?
What?
What
does
the
use
case
here?
I.
E
D
Y
O
To
Joe's,
mind
I
mean
most
of
the
clutter
of
the
queries
that
the
client
gets
coming
out
of
a
cache.
So
if
the
I
mean
what
would
be
the
point
in
requiring
security,
it's
absurdly
hard
within
a
resin
tree
cursor
to
find
out
what
the
state
was
when
you
entered,
and
then
what
is
the
state
when
you
exited,
because
there
are
tons
of
recursions
going
on
all
the
time
and
some
of
them
are
secure.
Some
are
not,
and
I
mean
this
is
a
bit
to
the.
Z
At
the
code
madtown
said
I
so
I
maybe
I'm
not
understanding
something
here,
but
I
would
have
thought
that
end-user
signaling
would
be
a
thing
that
was
useful
between
the
stub
in
the
application
rather
than
between
reaker,
sir
in
the
stub,
because
wouldn't
wouldn't
this
be
the
stub
saying
yes,
I
got
my
answer
over
TLS.
Why
would
the
application
not
trust
that
I
say.
E
AA
Here
to
careÃ,
say,
and
so
in
the
HTTP
world,
where
we
do
have
signaling
Greenlaw
all
that
kind
of
stuff.
The
point
is
that
the
user
knows
that
they,
you
know,
can
safely
hit
submit
next
time,
although
they
don't
actually
check
the
link.
So
it's
a
whole
nother
thing.
The
reality
is
in
something
like
this.
It's
more
like
saying:
you
just
released
your
privacy
right,
it's
too
late.
The
signal
occurs
after
you've
already
disclosed
what
you've
done
so
I'm,
not
sure
that
there's
a
whole
lot
to
be
done
there.
G
Can
do
more
so
signaling
to
the
user
in
whether
it's
the
user
signaling
to
the
service
of
what
they
want
or
signaling
back
to
user?
What
the
result
was
is
a
super
complicated
problem.
It's
a
complicated
problem
when
the
user
is
only
talking
to
one
party.
In
this
case
we
have
a
user
talking
to
one
party.
That's
then
talking
to
another
party.
Actually
they
might
be
talking
to
how
thousand
parties
it
may
have
talked
to
those
parties
in
the
past.
AB
Daniel
arc
employed
by
the
Internet
Society,
but
I'm
speaking
for
them.
The
I
agree
with
what
decayed
you
just
said,
I
think
we
should
just
personally
I
think
we
should
really
look
at
how
I
don't
know
that
the
end
users
are
really
going
to
care.
We've
seen
this
right
now
right
and
look
we're
removing
some
of
the
signaling
for
some
of
the
other
places
that
are
out
there.
AB
On
that
note,
I
think
we
should
involve
the
people
who
would
actually
implement
said
signaling,
so
that
ain't
no
asking
the
browser
vendors.
If
we
gave
you
this
signal,
would
you
do
anything
with
it,
for
instance,
because
if
nobody's
going
to
actually
use
it
right,
I
think
you're
gonna
say
that
right?
If
he's
gonna
use
it
then
don't
bother.
Let's
move
on
to
the
next
item.
W
Nick
I
suggest
to
move
to
more
technical
topics,
because
we
can
waste
any
amount
of
time
on
discussion
about
signaling
without
actually
having
the
protocol.
You
know
we
are
not
going
to
signal
anything
useful
anyway,
so
we
as
DNS
resolver
implementers
badly
need
a
mechanism
to
signal
that
the
offer
the
website-
or
you
know
the
other
side-
understands
some
secure
transfer
protocol.
So
I
would
suggest
the
focus
on
this.
Otherwise
we
will
not
get
anything
before
it
anyway.
Okay,
yeah.
AC
Yeah
I'm
not
from
this
Elliot
layer,
I'm
not
far
off
from
what
he
just
said,
but
I
did
want
to
add
that
I
think
there's
an
overarching
question
here
that
the
IAB
should
look
at
I've
mentioned
this
to
Steven,
which
is
what
sort
of
end-user
signaling
is
actually
useful
in
a
more
systemic
way,
and
that
could
feed
back
to
you.
But
I
think
it
would
be
premature
to
go
there
now
and
it's
a
research
topic
actually
yeah
cool
yeah.
AD
AD
AE
Brian
Dixon
I
think
this
dovetails
with
policy
discovery
and
or
other
kinds
of
discovery
in
the
the
signaling
I
think
needs
to
be
to
the
application
not
to
the
user,
to
some
degree,
at
least
in
terms
of
supporting
certain
environments
such
as
the
enterprise
I,
think,
that's
an
area,
that's
complicated,
but
I
think
there's
a
lot
of
potential
to
find
solutions
and
I'm
definitely
committed
to
participating
in
that
contributing
ideas.
Thank
you.
Q
Sahra
Dickinson
one
other
thing
to
consider
is
I.
Think
that
what
seems
to
be
the
more
useful
signal
is
one
the
client
can
send
to
the
cursor
to
say:
please
don't
do
this
query
if
you
can't
guarantee
you're
going
to
do
it
over
a
private
channel.
Obviously
you
can't
enforce
that
there
were
cursor
honors
that,
but
we
have
something
similar
with
a
DNS
client
subnet,
but
the
client
couldn't
at
least
say
please
step
forward
by
IP.
So
I
don't
think
that's
a
simpler
problem
but
I
think
that's
more
useful
to
the
client
yeah.
H
B
So
for
the
last
couple
of
minutes,
do
you
people
have
important
questions
that
they
think
we
need
to
consider
when
we're
when
we're
doing
this
work
that
Alex
and
Ben
know
have
not
articulated
yet.
We've
got
three
key
ones,
but
everybody
always
seems
to
have
their
own
little
interesting
questions
and
here's
your
chance
to
bring
them
up
now.
My.
I
AF
I
B
P
P
Q
P
AG
H
This
fine,
it's
it's
up
to
the
working
group,
so
we've
started
with
the
vicki.
Then
it
was
proposed,
move
it
to
the
github,
because
it
was
more
easy
to
track
changes
into
contribute
to
a
document.
But
I
merely
it's:
what's
best
fit
with
the
working
group.
So
how
does
the
working
group
on
to
interact
with
this
document?
Yeah.
AD
H
So
the
move
to
the
kids
help
us
also
after
the
interim
meeting
and
from
the
requests
from
the
participants
from
the
midterm
of
the
mid
WebEx
meeting.
I
can
imagine
that
we
kind
of
update
also
on
the
mailing
list
that
there's
has
been
edits
on
the
github
repository
for
and
their
attention
point
their
attention
to
the
documents.
E
I
It's
Tim
well
I,
think
I
got
a
repo.
What
I
mean
I
think
there's
been
one
P
or
and
and
zero
issues
on
this
I
just
had
a
quick
look
and
there's
been
a
bunch
of
discussion
on
the
list,
so
editorial
changes
work
away
in
github.
That's
just
fine
text
to
get
up
keep
any
non
editorial
discussion
on
the
list.
I'll
get
the
Americans.
B
What
we
mentioned
earlier,
Dan
is,
is
that
at
some
point,
probably
on
a
minimum
either
the
requirements
are
gonna,
be
published
as
a
standalone
document
or
published
as
an
appendix
to
whatever
solution
document
we
put
forth.
So
this
document
is
really
just
to
collect
all
the
key
things
that
we
want
to
focus
on,
and
then
we
can
decide
which
ones
need
to
be
included
in
in
a
in
a
publish
the
RFC,
okay,
I.
AB
H
I
understand
so
yeah,
it's
something
first,
it
was
an
ID
we
we
got
after
the
Bangkok
long
meeting,
but
we
had
some
discussions
with
the
chairs
and
the
tutor,
and
then
these
collect
some
IDs
from
the
mailing
list.
So
this
document
is
also
kind
of
an
inventory
of
the
discussions
on
the
mailing
list
and
at
least
place
everything
together
search
rates
with
some
questions.
H
That
chairs
also
ask
what
does
the
users
perspective,
but
is
the
operating
perspective
and
to
start
the
discussion
and
I'm
fine
to
move
it
in
any
place
on
any
form
was
a
working
group,
but
this
is
kind
of
kick
starting.
This
discussion
here
we
have
here
now
have
kind
of
some
structure
to
think
about
and
organize
our
work
for
the
next.
So.
AB
I
guess
my
only
comment.
We
were
somebody
who
is
not
far
this
group
or
who
wants
to
know
what
we're
doing
in
this
group.
This
is
now
a
stealth
document,
because
it's
not
in
data
tracker,
it's
not
in
anywhere
that
anybody
would
know
unless
they
happen
to
follow
this
so
I,
just
think
from
a
transparency
point
or
something
to
know
what
this
group
is
doing.
AB
AB
B
So
so
let
me
see
if
I
can
simplify
this
a
little
bit.
We
were.
We
don't
want
this
document
to
be
a
gating
factor
for
some
of
the
other
documents.
So
that's
why
we
made
it
a
just
a
scratch
working
group
document
as
a
beginning
point:
if
people
want
to
see
it
as
an
internet
draft,
we
can
do
that.
It's
not
that
hard.
B
AD
Make
it
in
in
a
draft
they're
working
documents,
it's
fine,
the
cheap,
extremely
cheap
and
then
like,
then,
people
like
know
how
to
find
things
for
the
working
group.
They
know
how
to
like.
You
know
when
they
come
in,
they
download
the
agenda.
They
can
just
download
the
working
group
on
I.
Don't
that
conflicts
in
any
way
with
using
github
for
like
to
develop
iterations
of
the
draft
for
like
please
do
plus
one
okay.
AH
Q
So
the
original
document
was
actually
published
back
in
2015
and
it
was
the
first
document
to
come
out
of
deprived
and
in
the
abstract.
It
said
that
it
documented
the
privacy
issues
associated
with
the
use
of
the
DNS
by
Internet
users.
So
there's
a
couple
of
things
with
hindsight
to
note
about
this:
one
is
that
it
is
very
specifically
limited
to
privacy.
It
does
not
talk
about
security
or
trust
models
or
how
users
choose
which
was
over
to
use
it
was
based
on.
Q
It
was
simply
a
snapshot
that
was
based
on
the
way
DNS
was
deployed
and
used
at
the
time.
So
three
three
and
a
half
years
ago,
and
as
we
all
know,
that
has
changed
quite
a
bit
we're
doing
the
piece,
because
since
then
we
have
had
multiple
standards
based
in
deprived
and
Indo,
so
we
no
longer
in
the
world
where
all
DNS
goes
over
clear
text,
so
things
have
changed
alongside
that.
We
have
the
second
draft
that
I'll
talk
about
today,
which
is
the
best
current
practices
for
operators
who
offer
privacy
services.
Q
We
did
an
update
at
beginning
of
this
year,
but
only
with
very
minor
updates
compared
to
the
first
version
and
a
call
for
adoption
started
yesterday
or
the
day
before,
say.
Thank
you
to
everybody.
Who's
already
commented
on
the
list.
Please
take
a
look
and
add
your
comments
to
that
to
a
very
brief
survey
of
what
is
new
in
the
bids
compared
to
the
original
document.
In
the
current
versions
appears,
so
we
added
work
on
dot
and
doe.
That's
in
there
and
included
those
as
transports
that
users
can
use.
Q
Q
We
talked
in
the
we
added
information
and
describing
the
threat
to
user
data
in
the
server,
because
again,
there
could
be
additional
information.
If
it's
come
over
a
transport
that
has
tracking
elements,
we
talked
about
threats
to
being
able
to
authenticate
servers
over
encrypted
transports
and
blocking
of
encrypted
transports.
Q
So
the
question
at
this
point
is
if
it's
a
very
positive
feedback
about
adopting
this
document,
and
so,
if
that's
the
case,
how
does
the
working
brick
want
to
move
forward?
So
what's
missing,
or
what
still
needs
work
in
there
is.
One
question
is:
is
the
coverage
of
the
encrypted
transports
sufficient
bigger
questions
are?
Should
the
scope
of
this
document
actually
be
expanded,
given
that
new
questions
are
being
raised
about
threats
to
users
based
on
their
choice
of
is
over,
and
the
network
context
that
they're
in
now?
Q
Whether
or
not
this
document
is
the
right
place
for
that
I,
don't
know,
I
think
that's
a
decision
for
the
working
group
to
make
we're
also
seeing
work
on
discovery
mechanisms,
so
we
should
as
those
progress
we
should
probably
include
how
users
assess
and
choose
which
discovery
mechanisms
to
rely
on
I.
Think
that's
something
that
does
fit
here
at
some
point
in
the
future
and
as
a
last
question,
there's
a
lot
of
talk
about.
Where
should
lots
of
different
discussions
go?
Should
there
be
a
new
working
group?
Q
Q
C
Q
So
the
companion
documents
to
the
problem
statement
is
the
solution,
which
is
the
best
practices
for
operators
who
are
offering
at
least
one
privacy
preserving
protocol.
When
we
wrote
most
arted
on
this
document.
Originally
we
had
two
goals.
One
was
to
describe
the
operational
policy
and
security
considerations
for
operators
using
the
transports,
and
the
second
was
to
think
of
a
way
that
operators
could
publish
and
communicate
what
policies
they
are
at
and
practice
they
are
using
in
practice
to
users
to
help
with
informed
consent.
Q
Where
are
we
with
this
draft?
The
the
last
time
we
presented?
This
is
back
in
Montreal
because
there
wasn't
a
meeting
in
Bangkok
it
adopted
by
the
working
group
very
shortly
after
that
and
we've
currently
on
the
OT
revision,
which
came
out
just
in
March
this
year.
But
I
would
say,
there's
been
no
major
changes
since
it
was
adopted
back
in
August,
so
I'm
gonna
just
quickly
run
through
the
document
structure,
so
that
people
get
a
flavor
of
what's
in
here.
If
you
haven't
read
it
for
a
while.
Q
So
in
part,
one
of
the
document
where
we
talk
about
the
considerations
we
frame
those
within
three
contexts-
one
is
on
the
wire
so
between
the
stub
in
the
recursive.
The
second
one
is
in
the
server,
so
we're
talking
about
data
at
rest
and
third,
one
is
upstream.
So
that's
messages
on
the
wire
to
authoritative
and
sharing
data
with
third
parties,
and
so
what
we
do
in
the
document
is
for
each
of
those
contexts.
Q
We
enumerate
the
set
of
threats
that
there
are,
and
then
we
recommend,
mitigations
and
in
the
current
document
the
threats
are
taken
both
from
the
76
26
beers
and
from
the
privacy
considerations
for
protocol
development
document,
69,
73
and
then
there's
a
few
others
which,
which
are
actually
standalone,
then
for
each
of
the
mitigations.
We've
broken
them
down
into
three
sets.
So
we
say
that
there
are
we've
labeled
them
as
mitigations,
which
are
things
that
you
shouldn't
be
running
a
what
you're
calling
your
doing
as
privacy
service.
Q
Unless
you
are
doing
this
set
of
things,
so
that's
the
minimal
you
can
do
to
be
compliant.
The
second
is
optimizations,
which
are
things
that
improve
the
position
for
your
users,
and
then
the
additional
options
is
like
the
full
monty
of
this
is
everything
you
could
possibly
do
to
really
so
you
bring
up
your
service,
so
it
doesn't
correlate
exactly
to
a
traffic
light,
but
that's
one
of
the
places
we
could
go
with
it.
Akka
yeah.
AD
Q
AD
Q
Okay,
so
to
quickly
spin
over
some
of
the
things
that
fall
into
the
categories,
so
in
the
on
the
wire
section,
we
consider
both
protocol
and
service.
So
we
talked
about
your
protocol
selection.
We
talked
about
ensuring
your
offer
way
for
users
to
authenticate
your
service
and
the
varying
ways
you
can
do
that.
We
talked
about
certificate
management
because
that's
new
to
DNS,
we
talked
about
protocol
things.
You
can
do
between
the
stub
and
recursive
so
pad.
Should
you
pad
things?
Should
you
do
session
resumption?
Q
Should
you
do
cookies
or
if
your
do
any
of
those
you
shouldn't
require
the
client
to
do
it?
They
can
opt
out,
and
we
also
talked
about
ensuring
your
service
is
equally
available
on
clear
text
transports
and
on
encrypt
your
transport.
So
servers
aren't
at
a
disadvantage
if
they
choose
to
use
an
encrypted
transport
at
rest
in
the
server.
The
focus
here
is
really
aren't
primarily
its
data.
Minimization.
It's
don't
store
anything.
You
don't
need
to
anymore
if
you're
a
privacy
service
and
then,
if
you
do
have
to
store
stuff,
how
do
you
handle
it?
Q
We
talked
about
logging
and
if
you
are
going
to
log,
please
anonymizer
as
much
as
you
possibly
can
don't
use
the
data
that
you
have
to
track
or
correlate
users
across
other
services
that
they
might
use
from
the
same
endpoint
being
very
whereas
who
has
access
to
the
data
and
we
have
a
what's
rather
a
placeholder
for
defenses
against
cache
snooping
in
terms
of
the
data
sent
upstream.
So
we
talked
about
what
recursos
should
be
doing
in
terms
of
protocol,
so
you
should
be
doing
you
know
minimization.
Q
You
should
be
very
careful
about
how
you
do
ECS.
If
you
do
it,
you
could
run
local
route,
etc.
We
briefly
talk
about
how
you
might
want
to
employ
traffic
obfuscation,
particularly
for
privacy
services,
with
a
small
subset
of
users
and
how
you
can
then
let
your
users
hide
in
the
noise
of
upstream
traffic
and
we
go
on
again
to
talk
about
data
sharing
and
there
is
a
fair
amount
of
commonality
with
the
at
rest,
but
there
are
some
things
that
are
also
specific
to
sharing
data.
Q
The
second
part
of
the
document
is
the
policy
and
practice
statement,
and
this
is
nothing
more
than
a
framework
that
we
are
proposing
for
a
way
for
operators
to
publish
the
decisions
that
they
have
made
about
the
service.
It's
not
huge
at
the
moment.
What's
in,
there
is
about
two
and
a
half
pages
of
text.
It's
just
a
list
of
you
should
say
something
about
this.
Something
about
this
something
about
this.
The.
Q
What
we
hope
is
the
usefulness
of
this
is
that
it
will
allow
operators
to
publish
their
data
and
their
policies
in
a
similar
way
to
provide
consistency
of
representation
for
users
who
want
to
consume
or
analyze.
This
now
there's
several
hours
and
days
of
my
life.
I
will
never
get
back
from
sitting
and
reading
policy
statements
from
just
the
big
three
quad
services.
Q
Trust
me
I,
my
guess
was
I
read
about
5,000
lines
of
texts
in
over
20
different
locations
in
order
to
track
the
chain
of
policies
that
tell
me
exactly
what
is
going
on,
so
it
is
non
non-trivial
for
even
a
technical
user
to
get
a
really
clear
picture
at
the
comparison
of
these
services.
So
we've
heard
a
lot
of
times
this
week.
Q
Informed
user
choice
and
consent
is
really
important
here,
so
that
one
of
the
goals
of
this
is
to
enable
that,
by
collating
information
in
a
common
form
from
users-
and
we
also
think
that
this
is
the
best
way
to
provide
the
basis
for
external
audits,
which
are
another
key
element
in
terms
of
I'm
an
operator
I
say:
I
do
X.
How
do
you
know
I
really
do
so.
This
would
be
the
basis
of
an
evaluation
or
monitoring.
If
you
could
give
you
ideally
if
you
can
actually
do
it
by
monitoring
rather
than
requiring
an
audit.
Q
So
as
an
exercise
to
this
end,
we
try
to
use
the
proposed
framework
and
we
try
to
look
at
for
the
privacy
policies
of
four
providers
when
we
originally
did
it.
Google
didn't
do
dots,
they
do
now
and
Open
DNS
doesn't
do
dot,
but
obviously
cloud
four
and
quad
nine
D,
but
it
was
just
a
let's
mix
and
match
and
see
how
useful
this
is.
Q
We
used
to
have
some
results
in
the
document,
but
because
we
of
the
table
structure
in
a
document
we
just
found,
we
couldn't
display
it
properly
here,
so
we've
actually
moved
the
results
onto
DNS
privacy.
There's
a
link
in
the
document
to
this
work,
and
at
this
point
it's
research,
that's
informing
how
we
do
the
framework
and
will
not
necessarily
be
in
the
document
when
it's
published,
but
to
give
you
an
idea
of
how
you
transform
five
thousand
pages
of
text
into
an
analysis
of
the
policies.
We
have
two
tables
on
the
website.
Q
The
first
one
is
the
policy
comparison
and
apologies
that
this
probably
does
still
really
look
small
so
that
the
sides
and
have
a
look
or
go
to
the
website
and
but
what
we
want
users
be
able
to
do
is
look
at
information
like
this.
Here
we
compare
quad
nine
actually
offered
two
services
with
different
characteristics
on
different
IP
addresses,
we've
got
cloud
flows,
dot
and
oh
and
we've
got
Google
and
opened
in
us.
Q
So,
for
example,
you
can
just
go
alright,
who
are
the
partners
of
the
person
I'm,
sending
my
DNS
data
to
and
can
I
even
find
out
what
they
are?
Are
they
stated
anywhere
or
what
does
this
operator
do
in
terms
of
filtering
where's?
The
statement
for
that
so
I
can
just
pick
and
choose
very
easily
based
on
my
requirements.
Q
Similarly,
there's
a
practice
comparison
so
again,
the
same
services
and
it's
quite
interesting
to
skim
this
and
oops
oops
and
see
things
like
yeah
at
a
glance
who
is
doing
dinner,
sack
not
everybody,
interestingly,
who
is
doing
query
no
minimization,
and
so
and
some
of
these
things
we
can
actually
test
for
by
monitoring
and
the
ones
that
we
can
test
for.
Sorry.
Q
Q
It's
limited
to
darts,
all
the
doc
resolvers
that
have
been
stood
up,
and
so,
whenever
people
just
don't
stand
up
dot
service,
they
tend
to
get
in
touch
with
us
and
say:
can
you
publish
my
details
on
your
site
because
at
the
moment
that's
the
best
out-of-band
way
to
publish
things
like
IP
addresses
and
credentials
so
down
the
side.
We
have
various
servers,
including
the
ones
run
by
the
stubby
developers,
quad,
nine
Google
and
Cloud
Player,
and
across
the
top
we
have
a
set
of
tests.
A
subset
of
these
are
things
that
are.
Q
We
are
recommending
are
part
of
the
policy
statement,
but
we
test
for
some
other
things
here
too.
So
you
can
see
if
I
highlight
one
way
there.
That's
quad
9,
Google
and
cloud
flare
and
going
across
the
way
we
look
at.
Do
there
for
TLS.
Do
they
offer
it
on
port
4
for
3?
Can
I
or
CENTAC
8
the
name
they
publish?
Do
they
provide
spki?
Pin
it's
a
certificate
currently
valid.
Do
they
do
cue
name
minimization?
Q
Do
they
do
dinner
SEC?
Do
they
do
keep
live?
Do
they
pass
their
answers
to
do
TLS
1.3?
Do
they
do
ask
forward
responses
so
wherever
we
can
we're
trying
to
do
that,
and
what
we
haven't
found
yet
is
any
discontinuity
between
what
these
operators
say
they
do
and
what
the
subsets
things
we
can
probe
for.
Okay,.
AD
AD
Very
good,
so
it's
just
a
right,
okay,
so
right
by
me,
but
the
but
the
implicit,
the
the
implicit
thing
is
like.
We
think
that
that's
not
good,
because,
like
the
red
exclamation
point
like
it
like,
this
is
bad
right.
So
I
guess
I
was
wondering
how
you're
gonna
handle
on
more
neutral
properties
such
as
blocking
right,
yes,
I
mean
like
because,
like
that's
a
different
table,
that
is
like
more
like
think
about
figure
out
for
yourself
yep.
So.
Q
What
we
were
thinking
of
doing
is
evolving
this
and
splitting
out
into
the
set
of
things
that
would
map
to
what's
in
the
compliance
and
trying
to
do
that.
But,
as
you
say,
some
things
we
will
have
to
be
very
careful
with
because
they're
subjective
you
know.
So
this
is
that,
there's
that
other
things
we
can
monitor
think
they
fall
into
two
categories.
There's
the
from
protocol
perspective.
You
should
be
doing
that.
Yes,.
AD
AD
I
would
actually
suggest
that
there
are
perhaps
a
slight
difference
on
me,
which
is
so
there's
there's
the
things
you
regular
things
you
on
like,
like
those
are
noticing
more
the
things
that
we
have
disagreement
on,
whether
they're
good
or
bad.
So
you
know
so
like
this
up
on
this
list.
Right
I
think
we
all
basically
agree
the
like.
AD
You
should
do
with
these
things,
so
it
seems
like
basically
you
know,
there's
the
policy
was
the
policy
say
there's
what
do
they
actually
do
and
like
and
then
did
they
disagree,
right,
yeah
and
so,
like
the
you
know,
so,
I
guess
and
qualitatively
like
they,
like.
The
policy
doesn't
reflect
like
the.
If
the
policy
doesn't
reflect
actual
behavior
like
Superbad.
AD
Like
you
know,
okay,
if
you
see
who
tells
we're
throwing
you
don't
that's
like
much
worse
and
like,
if
you
just
don't,
do
it
or
how
you
just
like
actually
like
so
so,
yeah
I
guess
like
I,
think
maybe
that's
the
way
we're
think
about.
It
is
like
the
sort
of
three
tables
I
think
table
which
is
here
are
some
things
which
you
might
might
I
want,
and
this
is
2002
Wilson
right,
likes
I
mean,
like
I,
think
great
examples
of
blocking
like
like
what
19
offers
blocking.
AD
Q
Thank
you.
That's
a
really
good
idea,
we'll
do
that
with
this
table.
One
thing
to
say
is
that
this
table
is
generated
off
a
single
vantage
point,
which
is
the
Synod
in
office
in
Oxford.
So
it's
you
know.
It's
certainly
possible
that
you
might
get
different
results
if
you're
looking
for
different
places.
So
one
thing
we
were
literally
talking
about
in
the
break
beforehand
is
what
would
be
also
really.
Q
If
you
talk
to
quad
a
over
UDP,
do
I
get
the
same
answers
as
if
I
talk
to
it
over
TLS,
because
I
know
nobody's
messing
with
the
TLS
ones
if
I
Center,
Kate
the
far
end
so
I
think
that
would
be
a
nice
thing
to
also
work
through,
so
that
you
could
validate
some
elements
of
what
you
think.
What
service
you
think
you're
getting
on
the
local
network,
Steven
sympho.
I
Just
on
the
last
point,
decker
mater
I
think
there's
there's
more
than
one
category
of
blocking.
Some
of
you
know,
there's
a
category
that
you
might
kind
of
opt
into
and
then
there's
another
category
that
you
might
need
me
told
about
so
I
think
that
I'm
not
sure
how
you
could
possibly
distinguish
those
things,
but
not
conflating
them
would
be
good
and.
I
Z
Q
Q
Should
we
split
out
the
data
handling
because
that's
possibly
an
earlier
problem
than
just
describing
what
you
should
do
in
terms
of
protocols
on
the
wire
and
should
we
actually
split
the
policy
framework
out
into
a
separate
document,
because
that's
a
standalone
thing
and
what
we
heard
was
support
for
doing
both
things
on
both
questions,
so
none
of
that
actually
ended
up
coming
to
the
list.
So
if
you
do
have
opinions,
please
bring
it
to
the
list,
so
we
can
make
a
decision
there.
Q
Some
of
the
other
questions
are
about
the
scope
of
this
document.
Even
since
we
started
writing
it,
that's
possibly
changed.
Should
we
have
more
detail
in
this
document
about
if
you're
an
operator
and
you're
a
DNS
resolver
and
a
CDN,
here's
some
things
you
should
and
shouldn't
do
or
if
you're
just
handling,
for
example,
doe
traffic
and
other
traffic
at
the
same
endpoint,
here's
some
things
you
should
and
shouldn't
do
so.
It's
possible
there's,
there's
ideas
on
that
that
should
go
in
here
and
I
guess
in
terms
of
moving
the
document
forward.
Q
I
think
that
the
chairs
might
want
to
come
on
this
as
well,
since
the
last
update
that
we
did
in
the
middle
of
last
year,
there's
been
very
little
discussion
on
the
list
about
certs
I
mean
so
the
question
is:
are
we
done
or
do
we
just
not
think
this
is
fit
to
be
a
doc
document?
It
should
stagnate
for
a
while.
Q
C
Q
AI
Think
this
is
a
I
mean
needs
to
be
settled
with
the
open
questions,
but
I
think
having
a
BCP
on
this
is
valuable
to
the
community,
which
is
why
my
name
is
there
too
I
hope
I'm,
not
like
opening
the
can
of
worms.
But
clarity
from
us
about
BCPs
are
for
clarity
about
us
from
us
about
the
value
of
some
operational
decisions
and
I.
Don't
see
a
reason
why
this
group
can't
can't
be
involved
in
one
of
those
sorry.
AJ
J
Le
PIR
I
also
thinks
good
and
it
should
be
published,
but
I
also
I.
Think
one
of
the
reasons
for
that
is
that
it
defines
some
terms
that
are
useful
to
cite
so
when
it
defines,
for
example,
levels
of
compliance
or
whatever
you
call
them,
in
the
degree
to
privacy
degree
of
privacy
afforded
in
three
levels.
That
is
an
interesting
thing
to
be
able
to
cite
and
refer
to
you,
because
it
can
use
that
in
protocol
signaling,
so
I
think.
Q
AB
Okay,
New
York
internet
society,
but
not
speaking
for
them,
the
I
would
I
to
support
doing
something
with
this
document.
I
think
it's
very
good
guidance
I
would,
though,
suggest
I'm
in
the
camp
of
splitting
out
the
d
ppppp
PPS
thing,
because
it's
a
different
audience,
because
I
know
having
worked
with
our
lawyers,
etc
around
writing
privacy
policies,
and
so
on.
You
know,
that's
that's
the
people
who
will
consume
some
of
that.
So
if
you
can
say
to
them,
we
want
one
of
these
go.
Look
at
this
document.
AB
Here's
the
guidance
for
how
to
write
this.
You
know
the
lawyers
or
others
engage
with
that
probably
will
not
want
to
weed
through
all
the
other
18
pages
worth
of
operational
guidance,
to
get
to
the
point
where
they
have
the
part
they
have
to
care
about
right
and
so
I
would
suggest
that
and
then
you
know
there
could
be
references
between
them
or
whatever.
So.
D
Christian
Witham:
oh
that's
a
nice
document,
but
some
of
the
discussions
like
the
discussion
on
how
to
use
TLS
and
how
to
not
leak
information
through
TLS
are
also
client-side
recommendations
and
it'd
be
nice.
If
we
had
these
clans.
That
recommendation,
as
in
for
example,
client,
should
be
very
careful
with
using
session
with
humans
in
the
third
and
and
basically
and
the
several
recommendation
should
be
essentially
don't
break
the
clients
that
are
taking
care
of
themselves.
I.
Q
Agree
and
for
a
while
we've
been
talking
about
doing
their
client
companion
to
this
and
I
think
now
would
be
a
good
time
to
start
that
document
I
think
there's
quite
a
bit
of
overlap
with
Vittorio's
drafts
and,
depending
on
you
know,
I'm
interested
in
working
groups
view
on
that,
because
that's
very
prescriptive,
almost
in
how
to
do
certain
things
and
I
think
if
you're
talking
about
a
client
and
if
you
go
down
the
road
of
doing
client
BCP,
you
probably
want
to
include
information
to
help.
Clients
choose
their
resolvers.
D
B
B
It
seemed
like
there's
interest
in
splitting
out
the
the
policy
things
which,
which
makes
a
lot
of
sense,
and
we
can
make
a
consensus
call
on
the
mailing
list
about
that,
and
I
also
heard
wanting
to
add
some
CDN
content.
Do
you
are
you
interested
in
soliciting
people
to
actually
help
provide
that
or
do
you
have
a
good
grasp
on
what
that
might
look
like
not.
B
At
a
minimum,
I
think
once
we
split
this
out
and
we
have
a
BCP
that
we're
happy
with
as
the
d-pryde
working
group.
The
easiest
thing
to
do
is
actually
just
ask
for
review
and
dns
top
and
make
sure
that
that's
a
part
of
the
review
process,
but
keep
the
document
ownership
here
so
that
the
people
who
are
most
interested
in
deprive
are
the
ones
who
are
involved
in
the
development
of
that
document.
Because.
Q
There
is
a
comment
in
the
document
that
says,
even
though,
in
terms
of
the
data
handling
we,
this
is
within
the
scope
of
privacy
services.
These
should
actually
be
considered
to
be
done
for
any
Dinis
operator,
so
there
is
a
overlap
there
and
I
guess,
that's,
maybe
the
point
at
which
just
DNS
up
want
to
decide.
They
want
to
start
specifying
some
of
these
four
as
recommendations
for
all
operators.
Q
B
N
Q
N
Q
AK
Thank
you,
hi
I'm,
Victoria,
Grall,
Tola
and
I'm,
actually
I'm
still
an
ITF
new
hammer,
so
just
to
give
you
an
idea
of
incoming
phone
so
to
explain
why
maybe
the
document
is
built
in
a
certain
way.
I
was
involved
for
like
20
years
in
the
rest
of
the
internal
governance,
places
like
I
can
and
so
on,
but
still
here,
I'm
a
human,
a
new
camera
and
I
was
told
that
to
start
the
discussion,
I
had
to
write
the
draft,
and
so
this
is
what
I
did
and
actually
I
I
started
from
the
same
consideration.
AK
That
was
already
done
so
that
I
saw
this
best
practice
document
for
the
operator
side
of
privacy
services,
but
I
mean
going
throughout
the
day
and
the
DRH
discussion.
It
appeared
to
me
that
there's
a
lot
that
needs
to
be
discussed
from
the
client
side,
and
so
I
said
why
don't
we
try
to
start
to
start
writing
advice
and
best
practices
for
the
people
that
write
the
DRH
in
the
OT
clients?
AK
So
I
mean
this
is
the
approach
that
I
have
taken,
so
I
tried
basically
to
take
the
other
document
as
a
starting
point
and
do
something
similar,
but
aimed
at
client
applications.
So
this
is
in
a
way
it's
complementing,
but
it's
pretty
different
from
the
other
to
do.
H
drafts
that
were
presented
in
the
new
age
group,
which
were
written
by
operators
trying
to
document
their
own
concerns
of
their
own
problems.
I
mean
the
idea
it
was
to
try
to
have
a
violin
of
all
the
issues
that
have
been
reported
by
different
parties.
AK
Some
of
these
issues
and
since
I
think
at
this
point
of
the
discussion,
more
or
less
everyone
agrees
that
the
problems
derive
from
the
deployment
policies
from
the
protocol
itself.
I
think
this
is
why
some
best
practices
on
how
to
deploy
it
is
necessary.
So
this
is
absolutely
not
meant
to
stop
the
the
deployment
of
encrypted
protocols.
AK
So
I
think
that
if
we
find
a
way
to
address
them
and
make
everyone
more
or
less
happy,
or
at
least
less
less
unhappy
about
these,
it
will
be
easier
to
get
it
deployed
and
also
this
is
in
the
end
there
I
mean
the
document
was
not
meant
to
attend
a
single
site
or
to
promote
a
single
side
of
the
story.
So,
of
course,
this
is
just
mine,
I'm
sure
that
there's
a
lot
of
stuff
in
it
that
doesn't
have
consensus
made.
Possibly
it
will
never
have
so,
of
course,
there's.
AK
There
would
be
a
lot
of
work
to
be
done
on
this
document
to
make
it
a
consensus
document,
but
I
really
tried
to
reflect
them
the
issues
and
also
the
advantages
of
the
DNS
and
critical
protocols
in
a
fair
way.
So,
if
I
failed,
of
course
happy
to
the
comments,
but
this
was
what
I
try
to
do
and,
of
course,
I'm
happy
to
incorporate
other
views
and
take
all
thor's
and
work
on
this,
so
I
mean
that
the
document
is
structured
as
an
advice
to
people
that
have
already
decided
to
deploy
a
liquid
client.
AK
So
this
is
why
there's
not
an
official
commendation
these
but-
and
the
attempt
is
basically
well
first
of
all
to
introduce
our
a
bit
of
terminology
because
I
think
we
still
like
it.
So
there's
still
a
discussion
on
how
to
call
certain
things
and
then
tries
to
break
down
the
issues
and
organize
them
in
some
way.
It's
not
entirely
doable.
AK
Since
many
of
these
issues
are
connected
together,
but
then
we
try
to
write
them
up
and
give
a
write-up
of
the
issue
and
in
the
end
there
are
some
recommendations
which
in
some
way,
I
mean
since,
as
I
said,
come
more
from
the
policy
side.
I
realized.
These
are
maybe
more
on
the
policy
side
that,
on
the
technical
side,
there
are
also
some
technical
ones,
but
path
of
them
could
be
to
policy.
So
this
is
also
part
of
the
discussion,
so
I
mean
well.
This
is
just
a
simple
and
I.
AK
Don't
know
how
many
people
here
actually
read
today.
The
draft
is
like
a
19
pages,
so
it's
not
actually
very
short,
so
just
to
give
you
an
idea
how
to
structure
this
really
a
bit
of
terminology,
mostly
related
to
defining
terms
like
local
or
remote
resolver,
and
the
different
models
of
having
members
which
will
happen
at
the
network
level
or
at
the
application
level,
and
and
then
this
is
the
list
of
the
issues
that
I
found
again.
AK
This
is
completely
up
for
discussion,
but
I
mean
I've,
seen
another
list
of
issues
shown
Wednesday
all
at
the
side
meeting
and
I
think
it
was
incomplete.
So
if
we
take
all
the
things
that
anyone
has
said
about
the
problems
that
have
been
caused
by
the
deployment
of
DHS
I
think
this
is
at
least
a
starting
list
missing,
maybe
there's
more
stuff
than
this,
and
and
so
in
the
end.
Just
to
give
you
an
example,
this
is
one
Lester.
AK
How
have
the
left
go
so
there's
a
description
of
the
issue,
an
argument
of
the
pros
and
cons
in
in
the
end,
some
suggesting
this
is
paraphrase:
it's
not
the
actual
text,
yeah
suggesting
that
application
should
do
certain
things
or
should
not
do
certain
things
and
so
on.
So
this
is
more
or
less
that
the
bulk
of
the
of
the
draft.
Q
AK
I
encourage
you
to
read
it.
If
you
didn't
so
I
mean
the
point
basically
is:
does
this
make
any
sense?
So
is
this
useful
I
mean?
Can
this
be
a
way
to
further
the
debate
to
discussion
in
a
productive
way,
rather
than
just
continuing
to
work?
We
do
one
against.
The
other
is
repeating
the
same
things
and
again
this
is
in
the
mandate
for
the
IDF.
Maybe
part
of
it
is
as
part
of
it
is
not.
AK
Maybe
this
could
be
focused
more
on
technical
stuff
and
the
policy
stuff
could
go
elsewhere,
but
again,
I'm
happy
to
take
feedback
on
that
and,
in
the
end,
we're
where
we
go
and
thus
I
think
this
discussion
needs
to
be
broadened,
so
I
mean
there
are
concerns
expressed
by
people
that
are
not
technical
and
are
not
in
the
IDF.
Maybe
those
are
concerns
that
I'll
not
to
be
addressed
at
the
IDF,
but
still
it's
something
that
we
have
to
discuss.
AK
AD
AD
I
think
this
the
arguments
about
what's
good
or
bad
and
the
recommendations
reflect
one
point
of
view.
That
is
not
a
consensus
point
of
view
and
I
cannot
imagine
those
getting
any
kind
of
consensus
on
ITF,
so
I'm,
not
only
sure
at
the
point
of
the
recommendations
is
I.
I
can
take
it.
You
know
you
about
the
previous
slide,
like
I
can
take
issue
with
it
bridge
everything
on
that
slide.
Much
that's
helpful.
AD
I
got
my
opinion
pretty
appreciate
for
Leah
that
this
I'm
eating,
though
I
suppose
that
most
informal
so
I'm
happy
to
do
here
too,
but
yeah
I,
think
you
know
some
of
this.
Some
of
these
things
I
think
go
wrong.
Some
of
these
things,
I
just
go
fight
EF,
but
I.
Don't
don't
I,
don't
think.
There's
any
like
I
knew
the
idea
that
the
private
is
gonna
come
up
for
like
a
set
of
recommendations
that
like
say,
for
instance,
that
applications
and
like
shouldn't,
like
the
resolvers
like
a
non-starter
yeah.
AK
AD
People
want
to
deploy
that
precisely
like
there's
a
certain
set
of
behaviors
on
the
network
that
are
causing
people
to
want
to
deploy,
applications
or
resolvers
that
do
not
get
the
resolver
choice
from
the
network
and
like
if
we're
gonna
have
a
documents.
Gonna
have
any
having
exists,
will
surely
have
to
cover
that
as
well.
AK
I
File
so
I
agree
that
I
heard
I
think
that
this
seems
to
be
a
yeah.
It's
a
tough,
been
written
by
somebody
who
has
a
problem
with
doing
what
we're
trying
to
do.
I
think
and,
let's
not
to
say
there
are
no
such
problems,
but
it's
not
kind
of
it
doesn't
seem
to
me
to
be
to
be
written
as
if
it's
finally
out
and
a
you
know
an
objective
set
of
technical
things
that
might
be
in
a
BCP
yeah.
So
I
think
this.
You
know
we
had
some
discussion
about,
though,
and
so
on.
I
M
M
AL
Mayor
I'm,
a
bit
surprised
by
the
choice
of
this
specific
example
that
you
give
after
the
list
of
issues
the
one
with
applications
doing
dns,
because
it's
something
that
is
completely
unrelated
to
privacy.
So
the
question
is
this
in
deep
rift.
Chatter,
then
the
answer
is
very
simple:
no,
it's
not
now
for
the
rest
of
the
of
the
issues.
I,
don't
think
there
is
well.
The
list
is
very
long.
Most
issues
are
completely
unrelated
on
for
the
question
is
this
in
the
Mandate
of
the
IETF?
The
answer
is,
it
depends.
AL
A
few
are
fully
in
the
Mandate
of
IETF
because
they
talk
about
protocols.
Some
are
partially
in
the
Mandate
of
IETF
constants
applications.
Doing
the
ordinary
solution
is
something
that
we
we
could
document
this.
We
could
document
the
consequences.
Flag
may
be
the
risk,
but
we
cannot
mandate
a
specific
behavior
from
application,
so
it's
only
partially
on
some
are
really
not
in
the
Mandate
of
IETF
on
sometimes
lead
I
mean
asking
for
consensus
is
completely
unrealistic
with
some
of
this
recommendation,
you
mentioned
in
one
slide,
no
two
alternative
routes
whoa.
AL
This
is
a
very
long
discussion
in
a
idea
from
other
places
and
I'm
fairly
certain
that
we
will
have
no
consensus
on
this
one.
So
my
suggestion
is
to
split
this
in
manageable
issues.
Stop
the
laundry
list
report
with
everything
I
can
think
about
Doh
doh-doh
dns
in
the
real
world
on
try
to
to
see
for
each
issue.
If
there
is
an
issue
most
of
the
time
not
everybody
will
agree.
Q
Sorry
to
consume,
firstly,
thank
you
for
this
document.
I
think
it's
a
really
good
starting
point
for
a
discussion.
I
think
it's
written
in
a
really
balanced
way.
I
have
two
comments
to
make
about
it.
One
is
that
I
think
if
we're
going
to
go
into
this
problem,
space
I
actually
think
it's
a
two
dimensional
problem.
We
have
different
classes
of
clients
and
they
can
be
human
users
and
they
can
be
applications.
Q
And
then
you
also
have
the
network
context
in
which
that
client
is
and
I
think
the
choices
that
get
made
are
actually
a
decision
of
both
those
faxes.
So
in
theory
we
could
expand
this
out
across
the
other
dimensions.
So
that's
one
comment
to
make
about
how
we
can
gather
all
the
information
in
one
place.
N
Watson
I
must
confess
to
only
having
briefly
read
it
I
think
the
concrete
recommendations
that
were
made
seemed
fairly
acceptable.
I'm,
not
sure
why
people
I
disagree
and
people
are
disagreeing
about
that
part.
I
do
think
document
bounds,
but
I
also
agree
with
sevens
point
that
this
is
a
broader
issue
which
which
is
being
decided
upon
where
the
forum
will
be
for
all
the
DHS
trees.
I've
been
raised.
I
think
this
document
is
squarely
going
to
fit
they're,
not
here.
AK
AK
AK
C
S
Hey
morning,
everyone
so
I'd
like
to
try
to
find
a
way
to
be
able
to
kind
of
separate
the
requirement
for
dot
from
DNS
SEC
in
some
way,
so
basically
for
what
would
happen
within
secret
delegations
and
I,
like
also
to
have
some
proper
signalling
that
we
make
this
same
so
I
mean
both
get
a
second
dot.
Basically
address
different
things.
S
So
the
authentication
stay
within
DNS,
which
is
a
property
that
we
may
want
to
have.
It
was
no
cloud
provider.
What
is
called
cloud
provider
here
says
is
essentially
suppose
you
get
the
zone
on
an
example
would
come,
and
they
may
use
example,
dotnet
and
example,
dot
all
to
serve
the
to
solder
zone,
and
there
may
be
a
totally
total
disconnect
between
who
the
donor
is
and
who's
the
name
servers
owners
up
each
name
server
can
also
end
all
its
secrets
on
its
own
so
like.
S
If
the
if
the
example
that
made
name
server
wants
to
change
the
key
want
to
rotate
it,
they
can
do
it
and
they
don't
have
to
involve
it
on
there's
a
longer
Dennis
is
required,
but
it's
only
required
at
the
name
server
level.
So
if
example.com
is
handled
by
example,
dotnet
and
org,
the
example.com
itself
doesn't
need
to
be
signed,
and
he
does
involve
an
extra
query.
What
was
mentioned
early
on
when
it
comes
to
discovery,
then
you
will
actually
need
to
do
an
x-ray
query
here
to
find
that
the
cheetah
cell
record
exists.
S
Another
thing
that
comes
to
mind
usually
is
to
use
the
API
and
the
x.509
certificates
in
this
case.
Basically,
you
will
just
connect
to
the
name
server
and
you
will
get
a
certificate
validates
against
the
the
host
name.
That
also
works
for
cloud
provider
case,
because
everybody
handled
the
uncertificated
and-
and
the
thing
is
in
this
case-
DNS
SEC
is
not
required.
S
S
The
if
you
here
is
pretty
much.
It
doesn't
really
work
well
with
with
cloud
providers,
because
you
got
you
got
this
DSP
ki
record.
That
will
say:
oh
the
we
support
dot,
but
then
you
may
have
one
cloud
provider
that
does
support
it
and
the
other
one
that
doesn't.
So
it's
pretty
much
all
of
nothing.
It's
also
these
entities,
external
entities
have
to
sync
up:
who
is
the
zone
owner
to
be
able
to
make
any
updates
on
the.
S
No
extra
queries:
there
is
a
signal
that
is
supported
and
yeah.
There
is
a
need.
The
the
cons
are
basically
need
when
you
are
type
and
chilli
change,
but
that
started
to
also
get
some
people
mentioning
that
we
could
maybe
overload
the
DES
record
type
and
basically
have
a
new
algorithm
that
will
contain
the
SPK
hash.
S
So
maybe
what
not
something
that
we
could
call
deal
nine
so
dog
or
whatever
is
we
did
so
many
of
them,
so
one
more,
which
is
basically
Diaz
and
in
this
case,
instead
of
having
the
spki
of
the
name
server
in
the
in
that
yes
record,
we
will
basically
hash
the
name
server
name
itself,
and
this
way
you
can
get
a
signal
that
the
name
server
supports
d-o-t.
So
that
adds
signal
to
the
x.509
from
before.
But
then,
essentially,
you
see
like
the
way
to
get
issue.
S
Finally,
this
was
just
a
hack
ID
that
the
ITF
103
hackathon,
which
was
a
DNS
coverage
like
implementation,
where
you
will
encode
the
spki
hash
into
into
the
name
server.
And
this
way,
as
you
query,
the
name,
the
DNS
record
for
for
example.com,
you
will
get
the
name
servers
and
then
you
can
get
a
signal.
That's
G
ot
support
you.
Then
you
get
the
ISP
I
hash.
These
fees
and
s
records
are
not
sign.
S
So
whatever
you
get
not
be
sure,
and
here
I'm
trying
to
basically
recap
everything
together
in
some
kind
of
traffic
light
type
of
things.
Whatever
is
read,
I
mean
there's
no
weights
between
these
these
columns
here.
So
some
things
may
be
bigger
blockers,
the
noses
that's
kind
of
where
the
trade
off
would
be
going,
keeping
in
the
approach.
S
What
I
hope
is
that
is
basically
I
mean
the
original
DSP
ki
approach,
like
Maeda,
made
a
few
other
people
kind
of
bring
ideas
like
the
overloading
GS
and
what
we
could
do
there
and
if
it
would
be
possible
not
if
that's
technically
possible.
I've
also
heard
that
operationally
may
be
hard
to
deploy
because
of
restrictions
from
the
registrar's
or
from
the
way
things
are
working
at
that
level.
But
hopefully
that's
going
to
start.
People
are
going
to
start
discussing
how
we
could
solve
that
eventually,
I'm,
not
saying
there
is
any
good
solutions
here.
S
P
Paul
Hoffman
for
your
last
row,
spki
named
the
red
block
under
cloud
provider.
Support
is
only
true
if
you
use
the
algorithm
you
gave
earlier
folks
had
just
suggested
not
to
tie
in
the
name
who's
there.
Just
the
key
at
which
point
a
cloud
provider
could
do
that,
but
it
doesn't
improve
it
a
lot,
but
it
does
remove
one
red
block.
Okay,
thanks.
J
But
Joey
I
believe
PIR.
Sorry
I've
got
a
question
because
I
hadn't
read
your
draft
before
and
I.
Don't
know
much
about
x.509.
So
is
this?
Is
it
the
case
that
every
time
an
individual
name
server
operator
wanted
role
a
certificate?
For
some
reason,
you
need
a
change
in
the
parent
zone
of
every
domain
that
used
that
name
server,
yeah.
S
J
To
be
I
mean
I
think,
for
example,
in
the
org
registry,
the
number
of
domains
is
much
bigger
than
the
number
of
name
servers,
so
it
suggests
there's
a
lot
of
name
servers.
Small
number
name
servers
serving
a
lot
of
zones,
potentially
there's
a
lot
of
dependencies
there
and
because
name
servers
are
not
really
live.
Actors
in
the
ecosystem,
there's
no
real
way
for
them
to
publish
their
information
that
other
than
you
know
you
might.
N
Once
I
think
there's
two
separate
things
that
we
shouldn't
be
conflating.
One
is
signaling
that
you
can
do
do
T
and
the
other
one
is
authenticating,
and
so
you
can
imagine
just
having
a
single
bit
field
saying:
yes,
you
can
do
do
T
and
then
separately,
having
a
sonication
I.
Think
x.509,
like
Tod
signaling
yeah,
just
doing
x.509
doesn't
give
you
that.
But
if
no
reason
you
can't
mix
that
in
with
some
DNS
level,
signaling
or
even
remembering,
which
name
servers
support
it.
S
N
R
He's
bring
it
up
from
the
under
maintenance.
Hello
pay,
different
I,
Cardenas
I,
really
like
the
as
in
do
9
I've
done
some
experiments
to
figure
out.
If
we
can
do
those
experiments,
it
turns
out.
Current
resolvers
are
all
compliance
in
that
they
go
and
secure
on
these
unknown
algorithms,
except
not
resolver,
which
was
fixed
yesterday
and
Google
Public
DNS.
Well.
My
ticket
is
currently
closed
as
works
as
intended
and
I've
Warren's
attention.
I
see.
Thank
you.
S
Actually
quickly
so
one
of
the
issue
in
the
tea
lake
hls
a
case
is,
you
can
get
some
signaling
and
basically
have
to
fall
back
to
to
DNS
over
53,
and
then
you
could
find
that
there
is
TLS
I,
recalled
and
know
that
they
do.
Does.
There's
also
the
issue
that
essentially,
you
need
to
do
some
probing,
but
we
could
also
think
about
ad
s
record
that
does
signal
that
the
server
is
supposed
to
do.
Cheerless
a.
AA
West
heard
occur
is
a
the
DNS
ecosystem.
Has
a
miserable
history
in
keeping
parent
children
synchronization
issues
in
check
and
I
would
even
so
badly
to
the
point
of
I
would
argue
anything
that
requires
a
child
update.
A
parent
record
is
a
non-starter
and
it's
a
real
problem,
and
you
know,
unfortunately,
that
might
mean
you
need
extra
queries.
You
know
is,
for
example,
but
a
lot
of
those
solutions
have
parent
transit,
synchronization
issues
and
we
suck
at
it.
Yeah.
S
This
is
something
I
put
actually
in
the
case
of
the
geo-9
util.
At
least
the
zone
owner
will
need
to
update
once
to
say
that
their
support
DNS
D
s
over
x509,
but
then
there
is
no
need
to
update
that
as
the
name
server
doing
your
date.
So
that's
kind
of
trade-off
that
may
be
fine.
Yeah
I
want
you
to
bring
those
different,
IDs,
I
think
the
the
table
here
should
be.
He
may
be
a
bit
more
granular
and
they
should
be
also
different,
shade
of
red
and
and
doing.
O
Yeah
they
become
I
mean
the
the
parent
kind
of
child
thing
was
point
out
enough,
I
mean
that's
really.
A
non-starter
also
involves
registrar's
writing.
What
have
you
I
think?
A
solution
has
to
be
sort
of
somewhere
at
the
child's
level
so
that
the
child
can
decide
and
it
has
to
be
the
intersect
period.
I
mean
we
didn't
do
linear
sect
for
years,
without
kind
of
now
doing
something
that
doesn't
required.
E
S
AM
AM
AM
The
assumption
is
in
an
enterprise
network.
If
you
bring
in
lon
MDM
device,
MDM
devices
can
easily
be
bootstrap
to
trust
the
locally
provided,
devotee
or
device.
So
this
is
a
case
where
you
bring
in
your
own
BYOD
device
into
the
enterprise
network,
in
which
case
you
know
the
credentials
to
authenticate
to
the
network.
So
you
basically
discover
and
authenticate
the
EC
server
is
T's
enrollment
or
secure
transport,
and
then
you
are
basically
authenticate
the
EST
server
using
a
peg
scheme.
AM
In
this
case,
I
picked
argumented
pick
scheme,
basically
TLS
SRP
to
authenticate
the
UC
server,
and
once
the
authentication
is
successful,
the
endpoint
can
fetch
the
CA
certificates
and
identity
certificates,
which
is
the
DNS
server
certificate
from
the
EST
server,
and
what
we
have
done
is
introduced
a
new
SR
SRV
ID
record,
basically,
so
that
the
client
can
identify
among
all
the
entity
certificates.
What
is
the
DNS
server
certificate.
G
AM
G
AM
AD
And
that's
what
we're
trying
to
it
right
so
like
whenever
I
see
like
a
presentation,
this
starts
with
some
likely,
however
acquire
means,
and
then
it
starts
like
this,
like
designing
security
protocols,
I
got
kind
concerned.
Can
you
like
tell
me
what
is
the
what
it
what
it,
what
what?
What
information
is
this
supposed
to
be
establishing
for
me
like
what
what
like,
like
I
I,
brought
my
client,
it's
like
getting
a
bunch
of
Network
messages
like
what
information
it,
what
it,
what
is
the
information
I'm
supposed
to
come
away
with,
so.
AM
You
just
connect
to
an
enterprise
network
and,
for
instance,
like
you,
get
a
message
saying
that
I
cannot
use
my
public
do
HR
DoD
server.
Then
what
option
do
we
have
today
so
to
either
it's
fallback
to
clear
text
right?
So
this
is
avoiding
that
option
that
you
can
have
a
secure
connection
to
the
enterprise
provider,
DoD
device
server,
okay,.
AD
AM
So
this
information
is
going
to
come
from
an
authentic
source
because
you
know
that
that
est
servi
authenticating
the
used
is
over
right
but
using
the
credentials
with
the
est
server.
Okay
like
unless
you
authenticate
the
UC
server
you
it's
a
network
provider,
DHT
server,
it
has
the
same,
it
should
have
a
representation
of
you,
username
and
password.
So
it's
it's.
It's
talking
to
Triple
A
server
hosted
in
the
enterprise
network.
So
it's
a
trusted
element
within
the
enterprise
network.
It's
not
some
character
who
is
hosting
the
e
so.
AN
Yeah
I
I
think
the
the
question
like
if
you
envision,
like
the
genera
Macbook
I,
plug-in
into
some
random
Network
like
there's
I,
feel
like
there's
a
behavior
switch
between
like
generic
public
network
behavior
and
managed
enterprise
network
behavior.
Are
you
presuming
this?
This
is
like
a
managed
device,
yeah
yeah.
So
what
yes?
So
the
question
is
like:
how
are
you
presuming
the
client
figures
out
that
it
needs
to
be
in
managed
enterprise
mode
as
opposed
to
generic
hostile
Internet
mode?
AM
AD
AM
AD
AM
AP
AF
AM
AF
AM
AD
AD
N
Its
DNS
SMP
I,
know
there's.
The
thing
is
I
believe
that
that
version
of
RFC
is
a
version
of
the
protocol,
which
has
a
two
for
one
password
guessing
attack.
There's
also
issues
around
the
password
hashes.
They
recommend
a
lot
more
Indies
to
be
there,
security
considerations
and
I'll.
Advise
you
to
wait
for
a
see
if
RG
do
actual
or
TLS
working
groups
to
have
a
modern
cake.
Something
like
opaque
could
probably
even
remove
a
couple
rounds
by
sending
information
you
want.
Yes,
yeah.
AM
N
I
Steam
file
I
share
Decker's
puzzlement
on
this
one.
Would
it
be
fair
to
say
that
you're,
a
bunch
of
people
who
are
used
to
dealing
with
EST
and
you
you
already
had
a
hammer,
so
would
that
be
fair
or
unfair?
Yeah
everybody
at
once
use
EST.
So
all
the
time,
yeah
right,
yeah
seems
weird
to
kind
of
use
that
kind
of
enrollment
kind
of
model
for
to
try
and
solve
the
problem
of
issues
with,
though,
come
up
by
passing
local
policy.
That
just
seems
like
a
really
weird
texture.
I
do.
AQ
So
one
kumari
google,
I
think,
just
like
steven
and
Ecker
I'm,
very
confused
in
the
serve
deployment
model.
I
get
the
I
arrive
at
business
with
phone,
and
it
helps
me
enroll
in
this.
What
I
do
not
understand
is
how
the
same
thing
can't
happen
at
you
know
a
Starbucks
or
something
like
that
right.
How
does
my
device
know
that
this
is
one
it's
supposed
to
enroll
with
and
that's
okay
and
reasonable,
and
that
other
one
isn't
and
I
think
that
that's
the
root
of
a
lot
of
the
confusion,
yeah.
AM
AR
Dns
draft
out
there
at
which
is
now
an
RFC
last
call
I
strongly
recommend
you
read
all
the
limitations
that
are
enforced
on
us
to
limit
these
kind
of
scenarios
where
you
just
take
over
a
DNS
server,
so
that
you
don't
raise
as
much
time
as
I
did
in
getting
people
happy
here
about
reconfiguring
their
DNS
on
the
fly.
Yeah.
Z
Yeah
thanks
Matt
pound
set.
Could
you
actually
back
up
to
your
problem
statement
slide
yeah
that
one
so
so
I
mean
I'm
going
to
observe
that
I'm,
actually
on
the
opposite
side
of
these
enterprise
case
argument
as
a
lot
of
the
privacy
people
who
are
here
in
in
that
I
think
we
need
to
solve
the
enterprise
issue,
but
I
think
you're,
starting
from
a
malformed
problem
statement,
which
might
be
part
of
the
reason
why
everybody's
confused
so
so
network
security
services
can
act
on
dough
or
rather
don't
need
to.
Z
You
know
to
find
the
right
way
to
phrase
this
so
that
it
covers
both
these
cases
but
network
security
services,
don't
need
to
treat
dot
and
doe
differently.
Necessarily
the
reason
they're
different.
Is
that,
though,
is
designed
to
design
to
bypass
that
sort
of
thing
right,
so
conflating
them
in
in
that
way
is
is
problematic
number
one
in
that
we
don't
actually
want
to.
We
don't
want
to
prevent
people
from
using
dot
and
oh,
we
want.
We
want
people
to
use
our
dot
and
oh
alright,.
AM
Z
Right
but
but
the
the
conflict
here
is
between
the
the
user,
who
either
trusts
DHCP
or
they
don't
and
if
they
don't
then
they're
treating
the
network
is
hostile
and
between
the
network
administrator.
Who
who
looks
at
the
application
as
either
they
accept
my
DHCP
data
or
they
don't,
and
if
they
don't,
that
application
is
hostile
and
the
you're
not
going
to
solve.
Z
That
second
case
through
configuration
and
in
the
first
case
you're
not
going
to
solve
that
through
more
management
configuration
you
have
to
solve
that
through
some
sort
of
other
trust
relationship
which
so
so
you
need.
You
need
prior
trust,
which
basically
boils
down
to
the
end.
You,
the
application,
is
either
going
to
accept
DHCP
or
they're
going
to
manually
configure
something
with
some
kind
of
prior
trust
agreement
and
so
yeah,
so
I
think
I.
Think.
Z
AN
What
we
have
here
is
a
tussle,
so
I
mean
I.
Think
to
your
credit,
you,
like
I,
think
you
have
accurately
described
the
state
of
the
art
in
terms
of
where
we
stand
in
this
tussle.
I.
Think
the
challenge
I'll
be
brief,
because
I
think
a
lot
of
people
have
said
this
pretty
clearly
like
we
do
I
think
there
is
a
use
case.
You're
like
there's
a
pony
somewhere
in
here.
AN
The
trick
is
like
figuring
out
exactly
where
in
this
use
case
space,
there
is
there's
you
you
haven't
you
you
land
in
a
territory.
It's
not
already
occupied
right,
because
we
understand
two
cases
pretty
well.
We
kind
of
nailed
down
two
ends
of
the
spectrum.
We
understand
the
totally
unmanaged
device
that
certainly
whatever
the
hell
it
wants
very
well
and
we
understand
the
managed
device
with
an
MDM
platform
to
this
explicitly
configured
by
the
owner
of
the
network.
To
do
the
right
thing.
AM
The
client
can
then
use
the
explicit
trust
or
downloaded
from
the
HT
server
to
validate
this
associated,
we're
considering
adding
a
new
privacy
certificate
extension
to
basically
convey
the
privacy
policy
with
regard
to
the
DNS
server.
What's
it
gonna
do
with
the
data,
especially
the
PA
data,
just
like
the
public
servers
are
giving
you
policy.
So
this
is
gonna
reflect
the
we
see
policy
of
the
local
dotd
where
server
so
that
the
user
can
make
an
concentrate
choice,
whether
he
wants
to
use
this
locally
provided
a
devotee
devoid
sir
or
not.
AM
The
xplit
trust
can
also
be
used
to
validate
other
readiness
of
cyclic
ups
that
happen
within
the
local
network
and
user.
Just
needs
to
I
mean
I,
don't
want
to
enable
this
in
an
every
Network.
So
I
go
to
a
network
where
I
work
day
in
and
day
out
and
I
know
that
hey.
That
network
gives
me
network
security
and
privacy
and
I
want
to
use
that
in
those
networks
only
and
if
the
user
trusts
the
network's,
then
the
user
can
enable
strict
privacy
profile.
AM
B
AN
Two
seconds
Richard
yeah
I
mean
without
looking
at
the
Charter.
It
seems
like
the
this
group
has
done
some
thinking
about
discovering
you
know,
DNS
servers
that
provide
you
know
these
security,
enhanced
features,
and
so
to
that
degree
it
could
be
in
scope,
but
I,
don't
think
we
understand
the
use
case
here.
Quite
well
enough,
so
to
say
one
way
or
the
other,
but
with
with
any
finality
is
whole.
C
M
M
It's
a
little
unclear
what
we
have
a
two
minute
lock
and
it
also
could
be
a
completely
different
mechanism
and
I
suspect
that
we'll
need
to
understand
the
requirements
a
lot
lot
better
before
we
can
decide
whether
this
is
even
remotely
the
right
mechanism.
This
is
a
finding
mix
of
acronyms.
From
my
perspective
and
I
can
I
can.
B
B
Not
Sean
no,
but
if
you
guys
can
help
coordinate
that
effort
with
the
with
the
different
working
groups
related
to
the
DNS
over
pick
your
favorite
transport
protocol,
and
let
us
know
that
would
be
great
all
right.
We
are
now
three
minutes
over
unless
somebody
has
something
critical
like
your
hotel
room
is
on
fire
and
you
want
to
let
them
know
we're.